Re: [Bloat] Bufferbloat test measurements

[Alan Jenkins <alan.christopher.jenkins@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3614 bytes --]

On 27/08/16 18:37, Kathleen Nichols wrote:
> In-line below. Only for geeks.
Present.

> On 8/27/16 9:03 AM, Alan Jenkins wrote:
>> That's the simplest measure of bufferbloat though :).
> Don't I know! :)  Have spent a couple of years figuring out how to measure
> experienced delay...
>> Do you have a criticism in terms of dslreports.com?  I think it's fairly
>> transparent, showing idle v.s. download v.s. upload.  The headline
>> figures are an average, and you can look at all the data points.  (You
>> can increase the measurement frequency if you're specifically interested
>> in that).
> "Criticism" seems too harsh. The uplink and downlink speed stuff is great
> and agrees with all other measures. The "bufferbloat" grade is, I think,
> sort
> of confusing. Also, it's not clear where the queue the test builds up is
> located.
> It could be in ISP or home. So, I ran the test while I was also streaming a
> Netflix video. Under the column "RTT/jitter Avg" the test lists values that
> range from 654 to 702 with +/- 5.2 to 20.8 ms (for the four servers). I
> couldn't
> figure out what that means.

My assumption is the RTT is just read out from the TCP socket, i.e. it's 
one of the kernel statistics.

http://stackoverflow.com/questions/16231600/fetching-the-tcp-rtt-in-linux/16232250#16232250

Looking in `ss.c` as suggested, the second figure shown by `ss` is 
`rttvar`.  And that's the kernel's measure of RTT variation.  If my 
assumption is right, that would tell us where the "jitter" figure comes 
from as well.

>   I can see the delay ramp up over the test
> (the video
> stream also follows that ramp though it's normal delay ranges from about
> 1ms to
> about 40ms). If I took the RT delay experienced by the packets to/from
> those servers,
> I got median values between 391 and 429 ms. The IQRs were about 240ms to
> 536-616ms. The maximum values where all just over 700ms, agreeing with
> the dslreports
> number. But that number is listed as an average so I don't understand?
> Also what is the
> jitter. I looked around for info on the numbers but I didn't find it.
> Probably I just totally
> missed some obvious thing to click on.
>
> But the thing is, I've been doing a lot of monitoring of my link and I
> don't normally see
> those kinds of delays. In the note I put out a bit ago, there is
> definitely this bursting
> behavior that is particularly indulged in by netflix and google but when
> our downstream
> bandwidth went up, those bursts no longer caused such long transient
> delays (okay, duh).
> So, I'm not sure who should be tagged as the "responsible party" for the
> grade that the
> test gives. Nor am I convinced that users have to assume that means they
> are going to see
> those kinds of delays. But this is a general issue with active measurement.
>
> It's not a criticism of the test, but maybe of the presentation of the
> result.
>
> 	Kathie

Thanks.  I wasn't clear what you meant the first time, particularly 
about the 40ms figure.  Very comprehensive explanation of your point.

It's easy to rant about ubiquitous dumb FIFO's in consumer equipment 
:).  Whereas the queue on the ISP side of the link ("download"), can be 
more complex and varied.  Mine gets good results on dslreports.com, but 
the latency isn't always so good during torrent downloads.

I do have doubts about the highly "multi-threaded" test method. 
dslreports let you dial it down manually (Preferences).  As you say, a 
better real-world test is to just use your connection normally & run 
smokeping... or an online "line monitor" like 
http://www.thinkbroadband.com/ping :).

Alan

[-- Attachment #2: Type: text/html, Size: 4721 bytes --]