Re: [Bloat] Bufferbloat test measurements

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

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

On 27/08/16 20:18, Alan Jenkins wrote:
> On 27/08/16 18:37, Kathleen Nichols wrote: 

> 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.

Sadly I don't think anyone's volunteered to restore the GMane web 
interface yet.  NNTP is still searchable though.

I'm not sure whether the author is saying they _are_ showing kernel 
stats, or whether they ended up having to do their own RTT calculation.  
(This is the Justin who runs dslreports.com).

-------- Forwarded Message --------
Subject: Re: delay-under-load really helps diagnose real world problems
Date: Sat, 25 Apr 2015 12:23:28 +1000
From: jb <justin-rsQtcOny2EM@public.gmane.org>
To: Matthew Ford <ford-pYXoxzOOsG8@public.gmane.org>, bloat 
<bloat-JXvr2/1DY2fm6VMwtOF2vx4hnT+Y9+D1@public.gmane.org>
Newsgroups: gmane.network.routing.bufferbloat
References: 
<AE7F97DB5FEE054088D82E836BD15BE9319C249E@xmb-aln-x05.cisco.com> 
<22118EDD-F497-46F3-AC6A-A75C389DFBAB@isoc.org>

I have made the following changes a few hours ago:

Bloat latency stats run on every connection now except GPRS and 3G
if you don't seem them during the test (mobile), they should be there
afterwards.

Download phase waits for quiescent latency measurements, defined by
less than 2x the lowest ping seen, or it simply gives up waiting and
continues.

The flow stats table has combined stats per server, so the megabit per
stream are
summed and the other measurements are averaged. I'm not entirely trusting
of the RTT and RTT Variance numbers from Linux, they come from the TCP_INFO
structure but are probably heavily biased to the end of the connection
rather
than the entire connection. However the re-transmits are definitely ok and
the
congestion window packet count looks about right too.

that's it..



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