From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (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 C448521F5C6; Fri, 12 Dec 2014 09:44:19 -0800 (PST) Received: by mail-ob0-f169.google.com with SMTP id vb8so9227852obc.0 for ; Fri, 12 Dec 2014 09:44:18 -0800 (PST) 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=7+aOnL38xGQE99u+5wv+1Da1qkS6+IaAnZl1UjnhXtA=; b=W04cpOHle2cQXX8za8guEzZA0OExYD7MuJuhbXRDbAS1D66qS+/2EHiAamBcOdE4Lv /cgq51HkXPPUsLWHfSxJHEoH4hdoaiuYlBG+O+R65ZFlzgzVXNElHwl/ea5AgRTnjDig /bRmiEdheFeCUubg0fZX3HFf3865pRwIst8WgJ/nkBVAUvnED/Rljvlq+Um7vNGRDXR/ XJUNZoznjDIu+RcmZlA3aacXDw5niojNwwWYD7hNz4BERM+XHOKH2MZd3zs0VAfUsHTe 9Hqq2PVM3V6Kzdc0BdLpXJf2uiVSSul2cn113cF1sHxbL/BXiyQOa4T3QSxejMCSxALG wW1w== MIME-Version: 1.0 X-Received: by 10.60.57.10 with SMTP id e10mr10843573oeq.45.1418406258426; Fri, 12 Dec 2014 09:44:18 -0800 (PST) Received: by 10.202.227.77 with HTTP; Fri, 12 Dec 2014 09:44:18 -0800 (PST) In-Reply-To: References: Date: Fri, 12 Dec 2014 09:44:18 -0800 Message-ID: From: Dave Taht To: Jonathan Morton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: bloat-devel , "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] cake: changing bandwidth on the rate limiter dynamically X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Dec 2014 17:44:48 -0000 On Fri, Dec 12, 2014 at 7:59 AM, Jonathan Morton wr= ote: >> On 12 Dec, 2014, at 17:52, Dave Taht wrote: >> >> Now, it turns out that cake makes altering the bandwidth really easy, >> you can just change it from the command line. >> >> http://pastebin.com/Jr9s6EBW >> >> I am pretty sure changing it is currently pretty damaging to stuff in >> flight (don't remember), but it needent be. > > I don=E2=80=99t think it is harmful. All that happens is that the packet= issue deadlines start to be advanced at a different rate with each packet = transmitted. A change in the rate by that mechanism doesn=E2=80=99t cause = any packet flushing or other trouble. > > The flow-discrimination mode and the diffserv mode can also be changed in= the same way, but this is more disruptive; it may at least result in some = packets arriving out of order within flows, if not also some spurious drops= . But the network can tolerate that happening occasionally. Good to know. While fiddling with the idea a bit, I found that you can add a bandwidth limit to cake on the fly, but once added you cant remove it with the syntax at hand. I plan to start up a new debloat-testing tree after the new year, containing bits of cake, and wireless-next, where it might be easier to fiddle. I do plan to stick to x86_64 for a while on that until something lands that is solid and useful on an embedded system. (It is long past time I shelled out some cash for github (as storing a kernel there would wipe out my disk space allocation), and will probably store the new tree there, unless someone objects) ... in the meantime, my current patchset for cake, cake variants, and for all the other qdisc work under test is here: http://snapon.lab.bufferbloat.net/~d/codel_patches/ It applies against net-next, and linux-3.14. The *.deb files are a kernel build for the latest ubuntu release. And I did do a build of chaos calmer as a test containing a slightly older version of that patch set http://snapon.lab.bufferbloat.net/~cero3/chaos_calmer/ar71xx/ Which I have been running for nearly 2 weeks now on a test wndr 4300 box. Sadly, although cake works great, it seems to have about the same cpu limitations as htb+fq_codel, so further work on the ingress path seems needed on these low end cpus (or we need to give up and just find faster hardware). > - Jonathan Morton > --=20 Dave T=C3=A4ht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks