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 6EA5521F708 for ; Sun, 2 Aug 2015 13:07:36 -0700 (PDT) Received: by oihq81 with SMTP id q81so61574515oih.2 for ; Sun, 02 Aug 2015 13:07:35 -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=yIRpQfgJWU8kiy9x+1dGEA087sWCZKYI1xK0+F9pSo4=; b=WpHjdYiVql8Q8A1FRhoqLgkPhXHamFvd6XZqa+ST8YEh/SZUF99w/wUYGgF7YiPlYv LiHD7EQvGs9k6HQjDKCauwgaNCIK0HLi4jpsGnqNGOyeKqtF8sFh1Tv7N34R+lvcl7DI o1DBRiwh4vX7wvNyHPVqJV+6Tr/zTC1sdmgy9PWZrrOhmTSgdYPMrTU3ffWVA0WnVYMO OsouDb98CvqVkl6LBYHfNPPMl0dnOC4Jb8kjoyuIameVB5XHA+P5/zjAoqI57T2mZ2oj HsaXfGO6rsZqzLLy9SUfxLUAee8qI4mJntAz6uam0Akd0YEiFeiCC+vLPWTo8h0aZnnq +C6Q== MIME-Version: 1.0 X-Received: by 10.202.214.16 with SMTP id n16mr12618190oig.75.1438546055317; Sun, 02 Aug 2015 13:07:35 -0700 (PDT) Received: by 10.202.73.2 with HTTP; Sun, 2 Aug 2015 13:07:35 -0700 (PDT) In-Reply-To: References: <1437941360960.ed6ad09f@Nodemailer> <55B54BAE.5000002@gmail.com> Date: Sun, 2 Aug 2015 22:07:35 +0200 Message-ID: From: Dave Taht To: Benjamin Cronce Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] How to test Cake on TP-Link WDR3600 X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Aug 2015 20:08:04 -0000 On Sun, Aug 2, 2015 at 9:04 PM, Benjamin Cronce wrote: > > > On Sun, Jul 26, 2015 at 4:05 PM, Alan Jenkins > wrote: >> >> On 26/07/15 21:09, Alec Robertson wrote: >>> >>> I=E2=80=99ve just updated to the newest trunk release of OpenWRT Chaos = Calmer >>> (fresh install) and the SQM QOS from OPKG interestingly does include Ca= ke as >>> a qdisc but neither layer_cake.qos nor piece_of_cake.qos are available = as >>> setup scripts. >>> >>> I=E2=80=99m still trying out Cake so I=E2=80=99ll be back soon with som= e feedback. >>> >> >> You should find the cake option there does nothing? >> >> It'll only work if you have the "kmod-sched-cake" package providing >> /lib/modules/*/sch_cake.ko. It's only in Dave's recent experimental bui= lds. >> >> fq_codel is the more supported option and serves the same functions. If >> you can notice any difference yet, I think we'd love to hear about it. >> Currently I believe the noticeable differences are >> >> 1. if your router has TCP offloads enabled, cake undoes ("peels") it som= e >> to improve latency. (Getting this past review for mainline Linux sounds >> increasingly "interesting"). >> 2. for networks with many flows, cake works much harder to avoid "hash >> collision" (entirely?), so every flow gets a fair share. fq_codel defaul= ts >> to 1000 hash buckets (but collision probability will increase well befor= e >> that point, see "birthday paradox"). > > > I was wondering about this. I'm going off of memory, but I read a paper a > while back that said they tested link speeds from 500Mb/s to 2.5Gb/s and > they saw these same characteristics when sending over 10,000 flows over t= he > congested link. > > 1) Never more than 200 flows of data in the queue at any given time > 2) Never more than 30 flows with more than one packet in the queue at a t= ime > > The birthday attack of all 200 flows into 1000 buckets is pretty bad, but > most of those flows are not greedy at any given moment, it's mostly those= 30 > you need to worry about. The paper I was reading was talking about 10s of > thousands of flows, so I assume there are many greedy TCP flows, but only= 30 > have more than one packet in the queue at a time. Assuming this is true, = I > wonder what implications this has and what Cake typically sees. This is one of the exciting-for-research parts of cake, we can actually try real workloads and measure, rather than just math. I added the ability to track active flows in the current git head for the out of tree version. >Of course > 500Mb is much faster than most consumer connections, but they stated they > saw no difference in queuing even with a large difference in bandwidth. > Because these were not consumer connections, I assume buffers were proper= ly > sized even if FIFO. https://team.inria.fr/rap/files/2013/12/KMOR05b.pdf might be helpful to rea= d. good math. for what is tractable that way, anyway. > Again, going off of memory, I could have gotten a few things out of conte= xt, > but it seemed fairly strait forward. > >> >> >> 1) seems a real concern for some new routers. If you are affected you >> could add a boot script using ethtool. >> >> The idea is it's not optimal to disable offloads universally... maybe if >> you're sharing a usb drive from the router as well or something. Having >> cake handle it works as a great default configuration. (I just suspect >> Linux devs would ask why the feature can't be enabled on other packet >> schedulers, e.g. by using a stackable peeler qdisc). >> >> >> Alan > > > > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake > --=20 Dave T=C3=A4ht worldwide bufferbloat report: http://www.dslreports.com/speedtest/results/bufferbloat And: What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast