From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 32E4C21F2E1; Mon, 1 Sep 2014 10:01:47 -0700 (PDT) Received: by mail-oi0-f42.google.com with SMTP id v63so3714645oia.1 for ; Mon, 01 Sep 2014 10:01:46 -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:content-transfer-encoding; bh=uhkLNx1c7WNenqLj7LsWTcaNmskZJZg6WrL4q3TcE34=; b=so7t2/jWm3Yduy8kpyWldFOlAlWkisUe9+uGue+iv6HL1AuBR/AcXT+zq1cgIIjQWt VbSBEXwGTK10cmVlNepPD6c8VF53iET9TRkQ79cVhoxTmIPt+kMylUBzjJYE2ga75OvM b9a7bW5JDhUqFm7cJ2AWXzovj3jAM45wNo9/AiQofC52J7mOWQ2VJ0ASaNCZ4fyRBFh1 M+guryqGTvOCu0QyuKIHI7fXvq9oUVUzp93rM9aVqIV98OII1WVSCp54ZA0Zy+1XiR3e nr33iCmTb7tlpyLOuCLq9JNMDV0nLUwqSJ0Ig1nJ1XYuUczj74yBQ3XIQlqydoD1SB48 XZOA== MIME-Version: 1.0 X-Received: by 10.60.41.134 with SMTP id f6mr8504166oel.49.1409590906064; Mon, 01 Sep 2014 10:01:46 -0700 (PDT) Received: by 10.202.227.76 with HTTP; Mon, 1 Sep 2014 10:01:45 -0700 (PDT) In-Reply-To: <0DB9E121-7073-4DE9-B7E2-73A41BCBA1D1@gmail.com> References: <87ppfijfjc.fsf@toke.dk> <4FF4917C-1B6D-4D5F-81B6-5FC177F12BFC@gmail.com> <4DA71387-6720-4A2F-B462-2E1295604C21@gmail.com> <0DB9E121-7073-4DE9-B7E2-73A41BCBA1D1@gmail.com> Date: Mon, 1 Sep 2014 10:01:45 -0700 Message-ID: From: Dave Taht To: Jonathan Morton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "cerowrt-devel@lists.bufferbloat.net" , bloat Subject: Re: [Bloat] Comcast upped service levels -> WNDR3800 can't cope... 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: Mon, 01 Sep 2014 17:01:47 -0000 On Sun, Aug 31, 2014 at 3:18 AM, Jonathan Morton wr= ote: > > On 31 Aug, 2014, at 1:30 am, Dave Taht wrote: > >> Could I get you to also try HFSC? > > Once I got a kernel running that included it, and figured out how to make= it do what I wanted... > > ...it seems to be indistinguishable from HTB and FQ in terms of CPU load. If you are feeling really inspired, try cbq. :) One thing I sort of like about cbq is that it (I think) (unlike htb presently) operates off an estimated size for the next packet (which isn't dynamic, sadly), where the others buffer up an extra packet until they can be delivered. In my quest for absolutely minimal latency I'd love to be rid of that last extra non-in-the-fq_codel-qdisc packet... either with a "peek" operation or with a running estimate. I think this would (along with killing the maxpacket check in codel) allow for a faster system with less tuning (no tweaks below 2.5mbit in particular) across the entire operational range of ethernet. There would also need to be some support for what I call "GRO slicing", where a large receive is split back into packets if a drop decision could be made. It would be cool to be able to program the ethernet hardware itself to return completion interrupts at a given transmit rate (so you could program the hardware to be any bandwidth not just 10/100/1000). Some hardware so far as I know supports this with a "pacing" feature. This doesn't help on inbound rate limiting, unfortunately, just egress. > Actually, I think most of the CPU load is due to overheads in the userspa= ce-kernel interface and the device driver, rather than the qdiscs themselve= s. You will see it bound by the softirq thread, but, what, exactly, inside that, is kind of unknown. (I presently lack time to build up profilable kernels on these low end arches. ) > Something about TBF causes more overhead - it goes through periods of low= er CPU use similar to the other shapers, but then spends periods at conside= rably higher CPU load, all without changing the overall throughput. > The flip side of this is that TBF might be producing a smoother stream of= packets. The receiving computer (which is fast enough to notice such thin= gs) reports a substantially larger number of recv() calls are required to t= ake in the data from TBF than from anything else - averaging about 4.4KB ra= ther than 9KB or so. But at these data rates, it probably matters little. Well, htb has various tuning options (see quantum and burst) that alter it's behavior along the lines of what you re seeing from tbf. > > FWIW, apparently Apple's variant of the GEM chipset doesn't support jumbo= frames. This does, however, mean that I'm definitely working with an MTU = of 1500, similar to what would be sent over the Internet. > > These tests were all run using nttpc. I wanted to finally try out RRUL, = but the wrappers fail to install via pip on my Gentoo boxes. I'll need to = investigate further before I can make pretty graphs like everyone else. > > - Jonathan Morton > --=20 Dave T=C3=A4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article