<div dir="ltr">Hi Kathleen,<br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Aug 28, 2016 at 3:37 AM, Kathleen Nichols <span dir="ltr"><<a href="mailto:nichols@pollere.com" target="_blank">nichols@pollere.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In-line below. Only for geeks.<br>
<span class=""><br>
On 8/27/16 9:03 AM, Alan Jenkins wrote:<br>
><br>
> That's the simplest measure of bufferbloat though :).<br>
<br>
</span>Don't I know! :)  Have spent a couple of years figuring out how to measure<br>
experienced delay...<br>
<span class="">><br>
> Do you have a criticism in terms of <a href="http://dslreports.com" rel="noreferrer" target="_blank">dslreports.com</a>?  I think it's fairly<br>
> transparent, showing idle v.s. download v.s. upload.  The headline<br>
> figures are an average, and you can look at all the data points.  (You<br>
> can increase the measurement frequency if you're specifically interested<br>
> in that).<br>
<br>
</span>"Criticism" seems too harsh. The uplink and downlink speed stuff is great<br>
and agrees with all other measures. The "bufferbloat" grade is, I think,<br>
sort<br>
of confusing. Also, it's not clear where the queue the test builds up is<br>
located.<br>
It could be in ISP or home. </blockquote><div><br></div><div>I haven't found any cases where the queue builds up in the ISP yet.</div><div>The people who have got grades and do something about it, always fix them</div><div>by fixing their home router/modem either by aggressively introducing the kinds</div><div>of stacks developed here in this list, or simply applying more rough fixes such</div><div>as capping speeds. When they do that, their grade goes to A+ and the latency</div><div>does not rise during the fastest transfer rates their connections run. Which is,</div><div>after all, the easiest to demonstrate issue with excess buffer sizes.</div><div>If you consider the ISP relative to an individuals connection, is it unlikely</div><div>that said individuals contribution running their (necessarily capped) service at</div><div>full speed can fill shared, much higher speed, buffers within the ISP infrastructure</div><div>assuming the perfect world where ISPs are not over-subscribed..</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So, I ran the test while I was also streaming a<br>
Netflix video. Under the column "RTT/jitter Avg" the test lists values that<br>
range from 654 to 702 with +/- 5.2 to 20.8 ms (for the four servers). I<br>
couldn't<br>
figure out what that means. </blockquote><div><br></div><div>The jitter variation is a foot note, and not something that determines the</div><div>grade. I use it to discover connections that are poor or lossy but not </div><div>to draw any conclusions about the buffer bloat grade. The entire buffer bloat</div><div>grade is the data in the graph that ties together the latency experienced</div><div>during idle, upload and download. If you turn on 'hires' buffer bloat in preferences</div><div>you get finer grained sampling of that latency.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I can see the delay ramp up over the test<br>
(the video<br>
stream also follows that ramp though it's normal delay ranges from about<br>
1ms to<br>
about 40ms). If I took the RT delay experienced by the packets to/from<br>
those servers,<br>
I got median values between 391 and 429 ms. The IQRs were about 240ms to<br>
536-616ms. The maximum values where all just over 700ms, agreeing with<br>
the dslreports<br>
number. But that number is listed as an average so I don't understand?<br>
Also what is the<br>
jitter. I looked around for info on the numbers but I didn't find it.<br>
Probably I just totally<br>
missed some obvious thing to click on.<br></blockquote><div><br></div><div>Again, the grade for buffer bloat is based on the latency over the course of</div><div>the (hopefully) full speed download v the full speed upload vs the latency</div><div>during idle. The latency is measured to a different and uninvolved server.</div><div><br></div><div>Generally if a user does not use their connection to full capacity, latency</div><div>is acceptable (but obviously the buffers are still there, lurking). Bursts and</div><div>so on can discover them again but the effects are transient.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
But the thing is, I've been doing a lot of monitoring of my link and I<br>
don't normally see<br>
those kinds of delays. In the note I put out a bit ago, there is<br>
definitely this bursting<br>
behavior that is particularly indulged in by netflix and google but when<br>
our downstream<br>
bandwidth went up, those bursts no longer caused such long transient<br>
delays (okay, duh).<br>
So, I'm not sure who should be tagged as the "responsible party" for the<br>
grade that the<br>
test gives. Nor am I convinced that users have to assume that means they<br>
are going to see<br>
those kinds of delays. But this is a general issue with active measurement.<br></blockquote><div><br></div><div>The responsible party is almost always the modem, especially DSL modems,</div><div>that have buffers that are completely wrong for the speed set by the product</div><div>or ISP. For instance I still get an "F" grade because during upload, with my</div><div>very poor 1 megabit upload DSL sync, there is an enormous buffer and the</div><div>latency rises to over a second making typing anything impossible. The modem</div><div>tends to be the gatekeeper for the narrowest part of the flow of data and so</div><div>is the first to be revealed as the culprit by the tests. You can't really fix any</div><div>issues with buffer bloat without first sizing that right. Then, after that, there</div><div>may be other things to correct.</div><div><br></div><div>From looking at the data, the amount of excess latency tends to drop with</div><div>the higher product speed. So people on fiber and the faster cable connections</div><div>don't see nearly such high latency up-lifts. I imagine to some extent this is </div><div>because cable modem firmware has buffers sized for what they expect is</div><div>the highest speed connections are, and so the faster products tend to operate in</div><div>that area where it isn't as severe. Although one could argue that a 10ms increase</div><div>on a gigabit connection is just as bothersome as a 1000ms increase on a 1megabit</div><div>upload like mine, and both deserve an "F" grade, the fact is the consumer </div><div>with the gigabit connection is never going to notice that kind of latency increase</div><div>unless they're running a stock-trading program at home!</div><div><br></div><div>There is various information on how to fix an "F" grade on the site, and it is always</div><div>a challenge because it tends to boil down to : get rid of your ISP provided modem</div><div>or pressure your ISP to introduce better home equipment because it is bound to</div><div>be to the root cause of the worst of  it, and you can't fix the rest without fixing that</div><div>first. And that is often a difficult message to deliver.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
It's not a criticism of the test, but maybe of the presentation of the<br>
result.<br>
<br>
        Kathie<br>
<div class="HOEnZb"><div class="h5">><br>
> [random selection from Google]<br>
> <a href="http://www.dslreports.com/speedtest/419540" rel="noreferrer" target="_blank">http://www.dslreports.com/<wbr>speedtest/419540</a><br>
> <a href="http://forum.kitz.co.uk/index.php?topic=15620.0" rel="noreferrer" target="_blank">http://forum.kitz.co.uk/index.<wbr>php?topic=15620.0</a><br>
><br>
> It's more aggressive than a single file download, but that's not<br>
> deliberately to exacerbate bufferbloat.  It's just designed to measure<br>
> performance of prolonged downloads / streaming, in a competitively short<br>
> test.  "For our busy lives", as the overused saying goes.<br>
><br>
> (The initial summary only gives a grade.  The figure wouldn't be one of<br>
> the headlines their ISP advertises.  Saying "100ms" would confuse<br>
> people.  And the tests they're used to / compare with, show idle latency<br>
> instead.)<br>
><br>
> On 27/08/16 16:19, Kathleen Nichols wrote:<br>
>> Yeah.<br>
>><br>
>> I admit to muddying the waters because I think of the size of a buffer as<br>
>> being in megabytes and the size of a queue (latency) as being in<br>
>> milliseconds. I think the tests attempt to measure the worst possible<br>
>> latency/queue that can occur on a path.<br>
>><br>
>> On 8/27/16 4:46 AM, Rich Brown wrote:<br>
>>> It has always been my intent to define bufferbloat as *latency*. The<br>
>>> first sentence on <a href="http://www.bufferbloat.net" rel="noreferrer" target="_blank">www.bufferbloat.net</a> says, "Bufferbloat is the<br>
>>> undesirable latency that comes from a router or other network<br>
>>> equipment buffering too much data."<br>
>>><br>
>>> That definition focuses on observable/measurable values. It sidesteps<br>
>>> objections I've seen on the forums, "How could $TEST measure the size<br>
>>> of buffers?"<br>
>>><br>
>>> So what matters is whether the buffers (of any size) are filling up.<br>
>>> ______________________________<wbr>_________________ Bloat mailing list<br>
>>> <a href="mailto:Bloat@lists.bufferbloat.net">Bloat@lists.bufferbloat.net</a><br>
>>> <a href="https://lists.bufferbloat.net/listinfo/bloat" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/<wbr>listinfo/bloat</a><br>
>>><br>
>> ______________________________<wbr>_________________<br>
>> Bloat mailing list<br>
>> <a href="mailto:Bloat@lists.bufferbloat.net">Bloat@lists.bufferbloat.net</a><br>
>> <a href="https://lists.bufferbloat.net/listinfo/bloat" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/<wbr>listinfo/bloat</a><br>
><br>
<br>
______________________________<wbr>_________________<br>
Bloat mailing list<br>
<a href="mailto:Bloat@lists.bufferbloat.net">Bloat@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/bloat" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/<wbr>listinfo/bloat</a><br>
</div></div></blockquote></div><br></div></div>