From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 1FA493B25E for ; Sat, 27 Aug 2016 15:39:44 -0400 (EDT) Received: by mail-wm0-x232.google.com with SMTP id o80so36307185wme.1 for ; Sat, 27 Aug 2016 12:39:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=xSgRUpySkd7aYZmLbxfDov8USvpUo4GQ3dbLN0q+n5A=; b=lyuAh3mgunQksOFsSL3oDOQGABB16rigctmufoXixcXxm8ddeQNQzdJIhx7uAZ10zN 6uXEkUp5IgjPjSEGU8oEHxN04TBgw0GZhjPJFcIA3tKyVKYTu4pjsEXH3rJPxW0y7gt2 jJa3cqrbJnPwa+h/lSkwhd0fcmt83PyXBqQUb/35TbxVeU3MMaJtNsVGX5JND9GC48+C RQ1QXdNHFFG5y8vaOJGUFpvQK6639ai8PdbPQkb6aBHARgW28kQMU7Cl95B4w9tLK8V2 THii6ZYrGJ/T7RW4VlW36gRqb4P2zZStTi215jjX8xx9tjMdaCol67IPOSB8UI7usDvx NXtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=xSgRUpySkd7aYZmLbxfDov8USvpUo4GQ3dbLN0q+n5A=; b=BrqOadmRiDZmDA4i7wGwgImrBS+n+DlffZkvefiObsTh33Fm/9vwhkzVxaeBPaQMcT G3qc4WypbZ8shJhJgD/7KbYpq/QkAjTmmZC2hNYzzn3oxMBw6vf0p1UKiVrPcs7Pvmt5 SVHjQ6Q3jqAam1bmx2LkA4HLV8365AvEp0lAo8HQj4tX2KNxiz0p6nhgfewal/Uv5gqW gcsxxz2VN73qOHUk9RT6wNqhq89V1g8ocxRDc9qruRyoEcY2G6Uek+p8zS455l545wh3 waJFYhNjEQJOKj6wa0L4OB2YdBJLoduXK8Gz0/rVKqpaQbSgnxdOsI5Tk6lQu2ucvOo5 lYeA== X-Gm-Message-State: AE9vXwOlklga5T6fHqa1wbQxyd9RYS4sQ2pu8OoyEKn2ssWR4F9Nu7uKtERivTen2B+tUg== X-Received: by 10.28.226.85 with SMTP id z82mr4093812wmg.101.1472326783054; Sat, 27 Aug 2016 12:39:43 -0700 (PDT) Received: from localhost.localdomain (host-89-243-172-136.as13285.net. [89.243.172.136]) by smtp.googlemail.com with ESMTPSA id z17sm5086691wmz.23.2016.08.27.12.39.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 Aug 2016 12:39:41 -0700 (PDT) To: Kathleen Nichols , bloat@lists.bufferbloat.net References: <05056A85-894D-477F-A10D-C912C7D52C2F@gmail.com> <448a25be-160f-701e-f56b-b3a33d49cff8@pollere.com> <63403b38-94fa-1670-908c-e14573f822a8@gmail.com> <8971f9f1-a79b-ce49-f7c4-660a355fdd43@pollere.com> <1091de30-017f-e6ee-a440-cd8425be0e1a@gmail.com> From: Alan Jenkins Message-ID: <1625876f-57ac-06c7-8202-e24081d9c491@gmail.com> Date: Sat, 27 Aug 2016 20:39:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <1091de30-017f-e6ee-a440-cd8425be0e1a@gmail.com> Content-Type: multipart/alternative; boundary="------------C659656F908974D919D1C4D8" Subject: Re: [Bloat] Bufferbloat test measurements X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2016 19:39:44 -0000 This is a multi-part message in MIME format. --------------C659656F908974D919D1C4D8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit 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 To: Matthew Ford , bloat Newsgroups: gmane.network.routing.bufferbloat References: <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.. --------------C659656F908974D919D1C4D8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 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..


--------------C659656F908974D919D1C4D8--