From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 3B27D21F29F for ; Tue, 21 Apr 2015 15:39:07 -0700 (PDT) Received: by qgdy78 with SMTP id y78so75376469qgd.0 for ; Tue, 21 Apr 2015 15:39:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YKmFVBvmy56h9XdlZoSktEIcVCg+Sh/sRGJpYrwT7GI=; b=g4+SOVQptClbRa2m0/0zgCTqZyUg+8NlfbFhxsEg6qt9ec33oaI0gH/A8JIdGCr2Kk 7e1Ss7w31hS4Q/7kC9RiWfHqjqBpgQzPEMEUVLgPRmBGgguSEu5evfuugGQ3RF0A7FaC cFPzY0rVwqzdU7TE+ZGWW+2/m4w4qhrOYzKynEXvm6E41p3UGgKyp2PYEc8yeCx8EtZq nPgg5tvSd4KVxweD/HvRaleEhCI8yBEd83ImeqUVZwPoiPfAjGcqX53TVVVIOYVGq8Vc UBY1F4fNqH65Qe0wE2zI/QMJhcI1UN/SG+HNGuLC9FwFBTXpp1h8bHFdcTssR7dY6vNG Alqw== MIME-Version: 1.0 X-Received: by 10.140.40.137 with SMTP id x9mr25567337qgx.75.1429655946677; Tue, 21 Apr 2015 15:39:06 -0700 (PDT) Received: by 10.96.187.71 with HTTP; Tue, 21 Apr 2015 15:39:06 -0700 (PDT) In-Reply-To: References: <75C1DDFF-FBD2-4825-A167-92DFCF6A7713@gmail.com> <8AD4493E-EA21-496D-923D-B4257B078A1C@gmx.de> <8E4F61CA-4274-4414-B4C0-F582167D66D6@gmx.de> <2C987A4B-7459-43C1-A49C-72F600776B00@gmail.com> <14cd9e74e48.27f7.e972a4f4d859b00521b2b659602cb2f9@superduper.net> Date: Tue, 21 Apr 2015 15:39:06 -0700 Message-ID: From: Aaron Wood To: jb Content-Type: multipart/alternative; boundary=001a11c123eeda5ac3051443b653 Cc: bloat Subject: Re: [Bloat] DSLReports Speed Test has latency measurement built-in X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2015 22:39:36 -0000 --001a11c123eeda5ac3051443b653 Content-Type: text/plain; charset=UTF-8 On Tue, Apr 21, 2015 at 3:13 PM, jb wrote: > Today I've switched it back to large receive window max. > > The customer base is everything from GPRS to gigabit. But I know from > experience that if a test doesn't flatten someones gigabit connection they > will immediately assume "oh congested servers, insufficient capacity" and > the early adopters of fiber to the home and faster cable products are the > most visible in tech forums and so on. > > It would be interesting to set one or a few servers with a small receive > window, take them from the pool, and allow an option to select those, > otherwise they would not participate in any default run. Then as you point > out, the test can suggest trying those as an option for results with > chaotic upload speeds and probable bloat. The person would notice the > beauty of the more intimate connection between their kernel and a server, > and work harder to eliminate the problematic equipment. Or. They'd stop > telling me the test was bugged. > Well, the sawtooth pattern that's the classic sign of bufferbloat should be readily detectable, especially if the pings during the test climb in a similar fashion. And from the two sets of numbers, it should be possible to put a guess on how overbuffered the uplink is. Then when the test completes, an analysis that flags to the user that they have a bufferbloat issue might continue to shed light on this. Attached is results from my location which shows a couple hundred ms of bloat. While my results didn't have congestion collapse, they do clearly have a bunch of bloat. That amount of bloat should be easy to spot in an analysis of the results, and a recommendation to the user that they may want to look into fixing that if they use their link at the limit with VOIP or gaming. I just wish we had a really good un-bloated retail option to recommend. -Aaron --001a11c123eeda5ac3051443b653 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Apr 21, 2015 at 3:13 PM, jb <justin@dslr.net> wrot= e:
Today I've switch= ed it back to large receive window max.

The customer bas= e is everything from GPRS to gigabit. But I know from experience that if a = test doesn't flatten someones gigabit connection they will immediately = assume "oh congested servers, insufficient capacity" and the earl= y adopters of fiber to the home and faster cable products are the most visi= ble in tech forums and so on.

It would be interest= ing to set one or a few servers with a small receive window, take them from= the pool, and allow an option to select those, otherwise they would not pa= rticipate in any default run. Then as you point out, the test can suggest t= rying those as an option for results with chaotic upload speeds and probabl= e bloat. The person would notice the beauty of the more intimate connection= between their kernel and a server, and work harder to eliminate the proble= matic equipment. Or. They'd stop telling me the test was bugged.
<= /div>

Well, the sawtooth pattern that's= the classic sign of bufferbloat should be readily detectable, especially i= f the pings during the test climb in a similar fashion.=C2=A0 And from the = two sets of numbers, it should be possible to put a guess on how overbuffer= ed the uplink is.=C2=A0 Then when the test completes, an analysis that flag= s to the user that they have a bufferbloat issue might continue to shed lig= ht on this. =C2=A0

Attached is results from my loc= ation which shows a couple hundred ms of bloat.=C2=A0 While my results didn= 't have congestion collapse, they do clearly have a bunch of bloat.=C2= =A0 That amount of bloat should be easy to spot in an analysis of the resul= ts, and a recommendation to the user that they may want to look into fixing= that if they use their link at the limit with VOIP or gaming.
I just wish we had a really good un-bloated retail option to r= ecommend.

-Aaron

<= /div> --001a11c123eeda5ac3051443b653--