On Tue, Apr 5, 2016 at 8:19 PM, jb <justinbe...@gmail.com> wrote: > I take your point regarding Quality
Thx! I am not grumpy at you in particular, but at a world that continues to view packet loss as completely undesirable (I was at several ietf meetings like that yesterday, and 2 days ago the FCC's "nutrition labels for broadband" got a lot of press: http://arstechnica.com/business/2016/04/fccs-nutrition-labels-for-broadband-show-speed-caps-and-hidden-fees/ ) Does anyone know how these nutrition labels are calculated? > but both your examples in the post show A+ quality? Well, yes... :) I did both of those with ecn on. (I did also get an A+ with ecn off) "desirable" packet loss, varies based on the number of flows, the targetted queuing delay, the bandwidth of the link, the tcp, and the RTT. It rapidly drops into the low percentage points for this particular test,for those particular parameters. as for: "Quality Grades Quality refers to average detected packet loss / re-transmit percentages during download phase. The higher the packet loss / re-transmit percentage the more inefficient the connection is, and a very poor result may be indicative of congestion, inside wiring issues or other problems that need addressing. "1% or less - A+ 2.5% or less - A 3% or less - B 5% or less - C 12% or less - D over 12% - F" What I specifically objected to was this formula for calculating the grade. After stewing about it a while (um, er, *years*, now), I realized last night that with a little work, now that we know what aqms such as pie and fq_codel can achieve, that we could, indeed, get a desirable range of "packet loss" for X flows, Y RTT, and Z bandwidth. btw: Does your test have the ability to track "CE" marks? That would be like a "gold star" affixed to the test report. (latest IoS has some support for ecn now by default) > I'm thinking that packet loss significant enough to show as a "C" or > worse is mostly a bad situation I pointed at a case where 25% packet loss was good here. http://localhost:1313/post/rtt_fair_on_wifi/ I am tempted to build on this theme, because it is not intuitive that desirable loss is a curve - a lot at low rates, but at higher rates, much less loss occurs and and really high rates one loss hurts... > even if avoiding all packet loss - by using huge buffers - is > definitely a disaster.. Yes. 0 and major bufferbloat would be an F grade for me, for "Quality" :) In other news, I sure wish the cable modems out there had followed these guidelines at least. http://www.cablelabs.com/wp-content/uploads/specdocs/CM-GL-Buffer-V01-110915.pdf > > > On Wed, Apr 6, 2016 at 12:21 PM, Dave Taht <dave.t...@gmail.com> wrote: >> On Tue, Apr 5, 2016 at 6:33 PM, Brandon Applegate <bran...@burn.net> wrote: >>> >>>> On Apr 5, 2016, at 9:04 PM, Dave Taht <dave.t...@gmail.com> wrote: >>>> >>>> Does anyone know what the "quality" portion of dslreport's metric means? >>> >>> Basically - packet loss. >>> >>> https://www.dslreports.com/faq/17930 >> >> Sigh. I ranted. I might rant harder. >> >> http://blog.cerowrt.org/post/bufferbloat_vs_quality/ >> >>> >>> — >>> Quality Grades >>> >>> Quality refers to average detected packet loss / re-transmit percentages >>> during download phase. The higher the packet loss / re-transmit percentage >>> the more inefficient the connection is, and a very poor result may be >>> indicative of congestion, inside wiring issues or other problems that need >>> addressing. >>> >>> 1% or less - A+ >>> 2.5% or less - A >>> 3% or less - B >>> 5% or less - C >>> 12% or less - D >>> over 12% - F >>> — >>> >>> >>> _______________________________________________ >>> Bloat mailing list >>> Bloat@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/bloat >>> >> _______________________________________________ >> Bloat mailing list >> Bloat@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/bloat _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
