From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-04-iad.dyndns.com (mxout-024-iad.mailhop.org [216.146.32.24]) by lists.bufferbloat.net (Postfix) with ESMTP id CA5762E00BA for ; Thu, 3 Mar 2011 18:24:57 -0800 (PST) Received: from scan-01-iad.mailhop.org (scan-01-iad.local [10.150.0.206]) by mail-04-iad.dyndns.com (Postfix) with ESMTP id 92A9E83454F for ; Fri, 4 Mar 2011 02:24:04 +0000 (UTC) X-Spam-Score: 0.1 () X-Mail-Handler: MailHop by DynDNS X-Originating-IP: 75.145.127.229 Received: from gw.co.teklibre.org (75-145-127-229-Colorado.hfc.comcastbusiness.net [75.145.127.229]) by mail-04-iad.dyndns.com (Postfix) with ESMTP id 67AAF834125; Fri, 4 Mar 2011 02:24:02 +0000 (UTC) Received: from cruithne.co.teklibre.org (unknown [IPv6:2002:4b91:7fe5:1::20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cruithne.co.teklibre.org", Issuer "CA Cert Signing Authority" (verified OK)) by gw.co.teklibre.org (Postfix) with ESMTPS id 0B0815EACA; Thu, 3 Mar 2011 19:23:59 -0700 (MST) Received: by cruithne.co.teklibre.org (Postfix, from userid 1000) id D8A521220C5; Thu, 3 Mar 2011 19:23:57 -0700 (MST) From: d@taht.net (Dave =?utf-8?Q?T=C3=A4ht?=) To: Jesper Dangaard Brouer Subject: Re: GSO Organization: Teklibre - http://www.teklibre.com 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> <1299054624.5900.36.camel@blue> Date: Thu, 03 Mar 2011 19:23:57 -0700 In-Reply-To: <1299054624.5900.36.camel@blue> (Jesper Dangaard Brouer's message of "Wed, 02 Mar 2011 09:30:24 +0100") Message-ID: <87vczz39oi.fsf@cruithne.co.teklibre.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Fri, 04 Mar 2011 02:24:58 -0000 Jesper Dangaard Brouer writes: > On Sat, 2011-02-26 at 03:41 +0100, Dave T=C3=A4ht wrote: >> Jesper Dangaard Brouer writes: >> > On Fri, 2011-02-25 at 17:33 +0100, Eric Dumazet wrote: >> >> Le vendredi 25 f=C3=A9vrier 2011 =C3=A0 16:48 +0100, Jesper Dangaard = Brouer a >> >> =C3=A9crit : >> >> >> >> > Disabling GSO on speed server fixed the problem as can be seen on g= raph: >> >> > http://people.netfilter.org/hawk/dropbox/bloat_vs_GSO/speed-to-gran= toften-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-gra= ntoften-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 a= nd >> > records the TCP sessions experienced delay. And the output can be used >> > directly by GNUplot. Nice! :-) >>=20 >> 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. So, thank you both for the HTB fixes (belatedly). There is at least one academic paper I've read fairly recently that is now thoroughly obsoleted by events. That said, I conflated two things in my question. The first was the old HTB problem.=20 The second was that your data has strong signals at exactly 10 and 20ms, which implies your tool or your kernel - or something else - is not using high res timers... ? > > > -- > 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 > > --=20 Dave Taht http://nex-6.taht.net