From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-11-iad.dyndns.com (mxout-222-iad.mailhop.org [216.146.32.222]) by lists.bufferbloat.net (Postfix) with ESMTP id 1E8732E0403 for ; Wed, 2 Mar 2011 00:31:11 -0800 (PST) Received: from scan-12-iad.mailhop.org (scan-12-iad.local [10.150.0.209]) by mail-11-iad.dyndns.com (Postfix) with ESMTP id 97D62171BA9 for ; Wed, 2 Mar 2011 08:30:27 +0000 (UTC) X-Spam-Score: 0.0 () X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 87.72.215.196 Received: from lanfw001a.cxnet.dk (lanfw001a.cxnet.dk [87.72.215.196]) by mail-11-iad.dyndns.com (Postfix) with ESMTP id 7A891171B9A; Wed, 2 Mar 2011 08:30:26 +0000 (UTC) Received: from [87.72.44.6] (lanvpn001a.cxnet.dk [87.72.215.222]) by lanfw001a.cxnet.dk (Postfix) with ESMTP id C809C163588; Wed, 2 Mar 2011 09:30:24 +0100 (CET) Subject: Re: GSO From: Jesper Dangaard Brouer To: Dave =?ISO-8859-1?Q?T=E4ht?= In-Reply-To: <87aahj7c0c.fsf@cruithne.co.teklibre.org> References: <4D6668F4.5010705@freedesktop.org> <4D668827.8060508@freedesktop.org><1298567313.2814.7.camel@edumazet-laptop> <87sjvds2r7.fsf@cruithne.co.teklibre.org> <1298575769.2659.10.camel@edumazet-laptop> <1298632912.21810.33.camel@traveldev.cxnet.dk> <1298634859.2659.44.camel@edumazet-laptop> <1298648937.28000.41.camel@traveldev.cxnet.dk> <1298651627.2659.84.camel@edumazet-laptop> <1298654104.28000.52.camel@traveldev.cxnet.dk> <87aahj7c0c.fsf@cruithne.co.teklibre.org> Content-Type: text/plain; charset="UTF-8" Organization: ComX Networks A/S Date: Wed, 02 Mar 2011 09:30:24 +0100 Message-ID: <1299054624.5900.36.camel@blue> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Wed, 02 Mar 2011 18:11:10 -0800 Cc: Jesper Dangaard Brouer , bloat-devel@lists.bufferbloat.net, herbert@gondor.apana.org.au, Eric Dumazet , Van Jacobson , shalunov@shlang.com, bloat@lists.bufferbloat.net X-BeenThere: bloat-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Developers working on AQM, device drivers, and networking stacks" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 08:31:12 -0000 On Sat, 2011-02-26 at 03:41 +0100, Dave Täht wrote: > Jesper Dangaard Brouer writes: > > On Fri, 2011-02-25 at 17:33 +0100, Eric Dumazet wrote: > >> Le vendredi 25 février 2011 à 16:48 +0100, Jesper Dangaard Brouer a > >> écrit : > >> > >> > Disabling GSO on speed server fixed the problem as can be seen on graph: > >> > http://people.netfilter.org/hawk/dropbox/bloat_vs_GSO/speed-to-grantoften-solved.png > >> > > >> > The really strange part when troubleshooting this issue was that the > >> > throughput as fine between the two customer end-boxes ("grantoften" and > >> > "pc314a") as can be see here: > >> > http://people.netfilter.org/hawk/dropbox/bloat_vs_GSO/pc314a-to-grantoften-1.png > >> > ... > > The graph is generated (with GNUplot) with data from the > > throughput-latency tool called "thrulay". Its created by Stanislav > > Shalunov, and its homepage is here: http://shlang.com/thrulay/ > > > > I really love this "thrulay" tool, as it measure both the throughput and > > records the TCP sessions experienced delay. And the output can be used > > directly by GNUplot. Nice! :-) > > I find the 10ms granularity on both graphs rather interesting. One of my > issues with HTB (when last I checked) is that it does odd things across > the clock interval. This case/graphs have nothing to do with the HTB qdisc. The traffic is not affected by the HTB shaper (on the path) as the customer actually have a 110Mbit/s bandwidth limit (as we always give customers 10% extra to avoid any complaints about overhead). If I change the customers bandwidth to 90 Mbit/s or 93 Mbit/s, which makes the HTB shaper (+the SFQ scheduler) have effect, then the customer experience is perfect, as I have solved the bufferbloat issue. The problem is of cause that marketing want to sell 100Mbit/s, not 90Mbit/s or 93Mbit/s. Thus, I cannot really implement the fix :-(. But, you memory is not totally faulted regrading HTB ;-) HTB used to be affected by the HZ clock interval, but I think Stephen Hemminger fixed that by using the highres timer API. And I fixed the "no_hyst" case where HTB could introduce spikes of three times the expected delay. -- Med venlig hilsen / Best regards Jesper Brouer ComX Networks A/S Linux Network Kernel Developer Cand. Scient Datalog / MSc.CS Author of http://adsl-optimizer.dk LinkedIn: http://www.linkedin.com/in/brouer