From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-x22a.google.com (ie-in-x022a.1e100.net [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id A0C2C200666 for ; Sat, 9 Feb 2013 14:36:34 -0800 (PST) Received: by mail-ie0-f170.google.com with SMTP id c11so6465020ieb.1 for ; Sat, 09 Feb 2013 14:36:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=QoQn1y+MHc8+XM7v11Wr/kyH8IIuiIgH8iZ1dF4DJ5w=; b=rKnR5DYjbQYC6xfbQ794+BnTZaO+4GD1KeuWx+Ix34I7k3SZTy/gk1mHd1NeVY/FnW wYxNv3yRUMRgOPTTpVlNxHPNq9os4zx/HtSkfoEqmle6Ot0ZG7cNIWTxBLyyJ3PnC5aV YNDr0O4GBzOtyudf+w7zKzwndJt6Jd6FiMZ1m7BG++TWWeRBIYRl5APQ6T7thgZkLeA+ H8Ftg8ZMgtEFw7VW+kZ+Ncf1zXyTmvUU2FTRBKJPEODh+pEc6TU6jtjXlcHPd2b9Rvbl f8UMSaKGFUeHI7gSVDcQo3VA7OAmhYWOiF2/lLSj9DnwIxMVuDxmXP6JHt2bT/qGXCi4 YHzA== MIME-Version: 1.0 X-Received: by 10.50.187.225 with SMTP id fv1mr8459142igc.96.1360449393944; Sat, 09 Feb 2013 14:36:33 -0800 (PST) Received: by 10.64.135.39 with HTTP; Sat, 9 Feb 2013 14:36:33 -0800 (PST) In-Reply-To: References: Date: Sat, 9 Feb 2013 14:36:33 -0800 Message-ID: From: Dave Taht To: Forums1000 Content-Type: multipart/alternative; boundary=14dae9340fe1dc683a04d5524e34 Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] I am unable to pinpoint the source of bufferbloat 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: Sat, 09 Feb 2013 22:36:34 -0000 --14dae9340fe1dc683a04d5524e34 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Feb 9, 2013 at 2:06 PM, Forums1000 wrote: > Excellent information. So an AQM-algorithm will sort things on the OS > level of the router and should make things considerably better. However, > from reading around on the matter, it seems drivers for the network devic= e > and the hardware itself also contain buffers. Since, Dave (and respect fo= r > that) is developing CeroWRT, is there anything that can be done about tha= t? > Do we have any idea on how severe the buffering in drivers and hardware i= s? > > In linux, it's got a lot better in the past 2 years. Work continues. I have some data on OSX now, and some on windows, but not a lot. In APs, routers, and switches, it's not looking very good. However I note that the second biggest place we see the issue is on the edge home gateways, dslams, cable head-ends, and many of those use software rate limiting, which generally has 1 buffer or less native to it, and the underlying buffering doesn't matter. (then on top of the software rate limiters are big fat dumb drop tails queues. currently. sigh) > A little test I just performed using Windows XP now, indeed shows that > Netalyzr is showing me a worst case scenario: > > Meh. Try something with window scaling. Or, try a netanalyzer test from some other machine at the same time you do this one. > - a continuous ping (1 ping per second) between 2 routers under my contro= l > has an RTT of 20ms (give or take). The remote router I'm pinging sits > pretty much idle and has nothing better to do than answering the ping. > - uploading a large file to Google drive (thereby saturating my uplink > bandwidth) adds +-10ms of additional latency. > I think this is an invalid assumption without actually measuring your transfer rate to the the gdrive. It would not surprise me if their TCP was pretty sensitive to latency swings, however, they are very on top of the bufferbloat issue. Wouldn't mind a packet capture of that upload while doing the above test. > Sure it varies a bit between 20 and 30ms and goes to 35ms or even 40ms > regularly. Moreover, every now and then I get a spike to 70-80ms but that > spike never lasts more than 3 pings. > > All in all considerably lower bloat than the 550ms Netalyzr is indicating= . > In order to mimic the worst case scenario, I'd have to transfer using UDP > then? > Just run a more modern OS.... > > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html --14dae9340fe1dc683a04d5524e34 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Feb 9, 2013 at 2:06 PM, Forums10= 00 <forums1000@gmail.com> wrote:
Excellent information. So an AQM-al= gorithm will sort things on the OS=20 level of the router and should make things considerably better. However, from reading around on the matter, it seems drivers for the network=20 device and the hardware itself also contain buffers. Since, Dave (and=20 respect for that) is developing CeroWRT, is there anything that can be=20 done about that? Do we have any idea on how severe the buffering in=20 drivers and hardware is?


In linux, it's got a lot better i= n the past 2 years. Work continues.

I have some data on OSX now, and= some on windows, but not a lot.

In APs, routers, and switches, it&#= 39;s not looking very good.


However I note that the second biggest place we see the issue is on= the edge home gateways, dslams, cable head-ends, and many of those use sof= tware rate limiting, which generally has 1 buffer or less native to it, and= the underlying buffering doesn't matter.

(then on top of the software rate limiters are big fat dumb drop tails = queues. currently. sigh)


=A0
A little test I just performed using Windows XP now, inde= ed shows that Netalyzr is showing me a worst case scenario:


Meh. Try something with window scaling. Or, try a= netanalyzer test from some other machine at the same time you do this one.=
=A0
- a continuous ping (1 ping per second) between 2 routers under my=20 control has an RTT of 20ms (give or take). The remote router I'm pingin= g sits pretty much idle and has nothing better to do than answering the=20 ping.
- uploading a large file to Google drive (thereby saturating my uplink=20 bandwidth) adds +-10ms of additional latency.
=
I think this is an invalid assumption without actually measuring your t= ransfer rate to the the gdrive. It would not surprise me if their TCP was p= retty sensitive to latency swings, however, they are very on top of the buf= ferbloat issue.

Wouldn't mind a packet capture of that upload while doing the above= test.

=A0
Sure it varies a bit=20 between 20 and 30ms and goes to 35ms or even 40ms regularly. Moreover,=20 every now and then I get a spike to 70-80ms but that spike never lasts=20 more than 3 pings.

All in all considerably lower bloat than the 550ms Netalyzr is=20 indicating. In order to mimic the worst case scenario, I'd have to=20 transfer using UDP then?

Just run a more modern OS....
=A0
<= /div>

___________________________________= ____________
Bloat mailing list
Bloat@lists.bufferbloat.net<= /a>
= https://lists.bufferbloat.net/listinfo/bloat




--
Dave T=E4ht

= Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscrib= e.html=20 --14dae9340fe1dc683a04d5524e34--