[Cerowrt-devel] ping loss "considered harmful"

David Lang david at lang.hm
Sun Mar 1 23:06:46 EST 2015

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 at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

More information about the Cerowrt-devel mailing list