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