From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 6D44221F181; Sun, 1 Mar 2015 20:06:49 -0800 (PST) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id t2246kTk022368; Sun, 1 Mar 2015 20:06:46 -0800 Date: Sun, 1 Mar 2015 20:06:46 -0800 (PST) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Dave Taht In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="680960-1289212444-1425269206=:26262" Cc: "aqm@ietf.org" , "cerowrt-devel@lists.bufferbloat.net" , bloat Subject: Re: [Bloat] [Cerowrt-devel] ping loss "considered harmful" X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 04:07:19 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --680960-1289212444-1425269206=:26262 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Sun, 1 Mar 2015, Dave Taht wrote: > On this thread over here, an otherwise pretty clueful user chose > openwrt's qos-scripts over the sqm-scripts, because sqm-scripts had > *higher ping loss*. > > > http://forums.dlink.com/index.php?topic=61634.msg251125#msg251125 > > (I note that both fq_codel enabled QoS systems outperformed > streamboost by a lot, which I am happy about) > > wow. It never registered to me that users might make a value judgement > based on the amount of ping loss, and in looking back in time, I can > think of multiple people that have said things based on their > perception that losing pings was bad, and that sqm-scripts was "worse > than something else because of it." People make the assumption that if ping packets are being dropped, their data is getting dropped as well. This is part of the "dropped packets are bad, so buffer so you don't drop packets" mentality To address this, the test results should first show all the stats without showing dropped packets, or if you need to show them, add a comment at that point that says that data packets are given priority over ping packets, so dropped ping packets don't imply that data packets would be dropped. David Lang > sqm-scripts explicitly *deprioritizes* ping. In particular, this > reduces the impact of ping floods from ipv6 to your entire /64, or to > your whole ipv4, fairly well. And I had made the point that > prioritizing ping was a bad idea here (including some dripping sarcasm > later in the piece). > > http://www.bufferbloat.net/projects/cerowrt/wiki/Wondershaper_Must_Die > > but wow, it never occurred to me - in all these years - that ping was > the next core metric on simple tests. I can be really dumb. > > I use netperf-wrapper and tend to ignore most of the ping data, but > certainly on some benchmarks we have published ping doesn't look as > good as the other stuff, *because it is deprioritized below all the > other traffic*. Not strictly rate limited - as some systems do by > default, including openwrt, which is impossible to get right - just > deprioritized.... > > How can we fix this user perception, short of re-prioritizing ping in > sqm-scripts? > > -- > Dave Täht > Let's make wifi fast, less jittery and reliable again! > > https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel --680960-1289212444-1425269206=:26262--