From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id AAE5521F2BD; Wed, 18 Mar 2015 03:39:29 -0700 (PDT) Received: from [192.168.150.14] ([134.76.241.253]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MA9FV-1YeY7424PR-00BKcY; Wed, 18 Mar 2015 11:39:19 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: <8BA791D1-E86E-4411-9081-1D1DC3D3D810@gmail.com> Date: Wed, 18 Mar 2015 11:39:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7D254F73-3A8D-41BF-8CCA-4A87B65D2211@gmx.de> References: <7081A75C-899A-4DB7-8D77-935A37B362D8@gmail.com> <8BA791D1-E86E-4411-9081-1D1DC3D3D810@gmail.com> To: Jonathan Morton X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:ON8nII2qw3UrHAfdwLjJqYj8vnwTqbNnHd68Xi9f6vEWn/u0iv/ FGyRcJLNAbH8I3W4IGPhI8cLvKKLDDPaiEebW0LjGX/jwaPi1k5UeJ+ORD92vQ/H7sW2N5l DwctCT5owp4fci3zlsYxnF6KNTQft4a2cYIgWi9i+oFT0rzPbwAgicCeBKV2P7jt3iS+8vl UOjZO5HqnlxO3e3ZMRB2w== X-UI-Out-Filterresults: notjunk:1; Cc: codel@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] [Codel] The next slice of cake 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: Wed, 18 Mar 2015 10:39:58 -0000 Hi Jonathan, On Mar 18, 2015, at 09:41 , Jonathan Morton = wrote: >> I wonder, are the low priority classes configured with a guaranteed = minimum bandwidth to avoid starvation? And will they opportunistically = grab all left over bandwidth to fill the pipe? Then speed test should = just work as long as there is no competing traffic=85 >=20 > The problem is that, in the present version, *only* the = bulk/background class can use the full pipe. Best effort gets a large = fraction as its limit, but it=92s not full. Existing speed tests use = best-effort traffic, and that=92s not likely to change soon. >=20 > The next version should change that. Great. >=20 >> I am probably out of my mind, but couldn't it help if cake would = allow a fixed cycle mode where it would process 50ms or so worth of = packets pass them to the interface, and then sleep until the next 50ms = block start. This should just be a fallback mode to not degrade badly = under overload=85 >=20 > There is already such a mode to cope with limited-resolution timers = and the existing overheads. Without it, the Pentium-MMX is limited to a = rather low rate (since it then has to wait for a timer interrupt for = alternate packets). At 50Mbps+, it=92s not too far off what it can = bridge without shaping (60Mbps+). For some reason, the little CPE boxes = still lose more performance than that to shaping. Excellent. >=20 > Note that due to the very nature of shaping, the link is always either = effectively idle (in which case an arriving packet is dispatched = immediately, without waiting for a timer), or overloaded (in which case = packets are delivered according to a schedule). The question is whether = the shaping rate also overloads the hardware. >=20 > In any case, bursting for fifty whole milliseconds at a time would = absolutely *destroy* cake=92s latency performance. I=92m not going to = do that. Accommodating timer performance is the only concession to = bursting I=92m willing to make. Well, I should not have put a number in, I know, I was mainly = trying to push for a batching mode to distribute the timer and context = switching costs over more work done, like the batching patches Jesper = got into the kernel. I guess I should look at the cake code and try to = understand what is happening ;) I think with HTB latency starts to suffer once the shaped rates = exceed the hardware=92s capabilities, so I think of this as a trade-off = between latency and bandwidth; if cake does not show this behavior but = just bounds the effective bandwidth instead of increasing latency the = whole configurable tradeoff idea might make not much sense ;) >=20 >> I think the highest priority band should only get its bandwidth = quota, and have no silent priority demotion; but otherwise I think that = idea that classes can pick up unused bandwidth sounds sane, especially = for best effort and background. >=20 > Let=92s see how well it works this way. It should be fairly easy to = adjust this aspect of behaviour later on. >=20 > - Jonathan Morton >=20