<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 27/08/16 20:18, Alan Jenkins wrote:<br>
<blockquote
cite="mid:1091de30-017f-e6ee-a440-cd8425be0e1a@gmail.com"
type="cite">On 27/08/16 18:37, Kathleen Nichols wrote:
</blockquote>
<br>
<blockquote
cite="mid:1091de30-017f-e6ee-a440-cd8425be0e1a@gmail.com"
type="cite">So, I ran the test while I was also streaming a
<br>
<blockquote type="cite">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.
<br>
</blockquote>
<br>
My assumption is the RTT is just read out from the TCP socket,
i.e. it's one of the kernel statistics.
<br>
<br>
<a class="moz-txt-link-freetext" href="http://stackoverflow.com/questions/16231600/fetching-the-tcp-rtt-in-linux/16232250#16232250">http://stackoverflow.com/questions/16231600/fetching-the-tcp-rtt-in-linux/16232250#16232250</a>
<br>
<br>
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.
<br>
</blockquote>
<br>
Sadly I don't think anyone's volunteered to restore the GMane web
interface yet. NNTP is still searchable though. <br>
<br>
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).<br>
<br>
-------- Forwarded Message --------<br>
Subject: Re: delay-under-load really helps diagnose real world
problems<br>
Date: Sat, 25 Apr 2015 12:23:28 +1000<br>
From: jb <a class="moz-txt-link-rfc2396E" href="mailto:justin-rsQtcOny2EM@public.gmane.org"><justin-rsQtcOny2EM@public.gmane.org></a><br>
To: Matthew Ford <a class="moz-txt-link-rfc2396E" href="mailto:ford-pYXoxzOOsG8@public.gmane.org"><ford-pYXoxzOOsG8@public.gmane.org></a>, bloat
<a class="moz-txt-link-rfc2396E" href="mailto:bloat-JXvr2/1DY2fm6VMwtOF2vx4hnT+Y9+D1@public.gmane.org"><bloat-JXvr2/1DY2fm6VMwtOF2vx4hnT+Y9+D1@public.gmane.org></a><br>
Newsgroups: gmane.network.routing.bufferbloat<br>
References:
<a class="moz-txt-link-rfc2396E" href="mailto:AE7F97DB5FEE054088D82E836BD15BE9319C249E@xmb-aln-x05.cisco.com"><AE7F97DB5FEE054088D82E836BD15BE9319C249E@xmb-aln-x05.cisco.com></a>
<a class="moz-txt-link-rfc2396E" href="mailto:22118EDD-F497-46F3-AC6A-A75C389DFBAB@isoc.org"><22118EDD-F497-46F3-AC6A-A75C389DFBAB@isoc.org></a><br>
<br>
I have made the following changes a few hours ago:<br>
<br>
Bloat latency stats run on every connection now except GPRS and 3G<br>
if you don't seem them during the test (mobile), they should be
there<br>
afterwards.<br>
<br>
Download phase waits for quiescent latency measurements, defined by<br>
less than 2x the lowest ping seen, or it simply gives up waiting and<br>
continues.<br>
<br>
The flow stats table has combined stats per server, so the megabit
per<br>
stream are<br>
summed and the other measurements are averaged. I'm not entirely
trusting<br>
of the RTT and RTT Variance numbers from Linux, they come from the
TCP_INFO<br>
structure but are probably heavily biased to the end of the
connection<br>
rather<br>
than the entire connection. However the re-transmits are definitely
ok and<br>
the<br>
congestion window packet count looks about right too.<br>
<br>
that's it..<br>
<br>
<br>
</body>
</html>