From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id ADF8D3B29E for ; Tue, 23 Jun 2020 12:08:07 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1592928483; bh=I8S3Kw3rDPOUcT1vBXR35O5we55s42izWgmtGr5yn2k=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=RdeQCJg4lqpGxQJH4Lj2Xlr/BP8LUY1/2trGItP4jFyxxJ2l4n0pWXGWkDUpHhkjW 5gVXP46idzZpHNRwY6/1fYVmhg42Qde8dJ6MAeywVYwZv2YjW2Ub3xAyGa1++OCfIn 4/MRlGEO4rn+hyAWZz7HllOiqtc9U7+nq03t72Yo= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [10.11.12.3] ([134.76.241.253]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MfHAH-1jCEzh3frv-00gsJm; Tue, 23 Jun 2020 18:08:02 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) From: Sebastian Moeller In-Reply-To: <8959B7A6-0B20-4812-BC9D-812DD4F3BCC4@gmail.com> Date: Tue, 23 Jun 2020 18:08:02 +0200 Cc: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , cake@lists.bufferbloat.net, marco maniezzo Content-Transfer-Encoding: quoted-printable Message-Id: <0D78908A-07BB-4398-BFD2-78858AB2B8E2@gmx.de> References: <877dvzt84w.fsf@toke.dk> <87lfkdrgip.fsf@toke.dk> <8959B7A6-0B20-4812-BC9D-812DD4F3BCC4@gmail.com> To: Jonathan Morton X-Mailer: Apple Mail (2.3445.104.14) X-Provags-ID: V03:K1:XIJZMAEJMccA76vkRrtS+0GUJlOZ8bCYfY+zP91BanoQzq/tKBm 2TbXyMWyruqWlao9Ct7deO6mmZihaA6XPcLGA40pqoPmgncyooS7VvtBzz78NOcq2D26gCC 1xJfPWvXP7s1s1ZFnEb7eOmpG+VLKlGKlJuDHE+dt4DEVVCfufrVrK6bKfHj7FIPA39qmJZ X9TJls6mQId7KJH92vssw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:oPhf+ik7GeM=:sljwpdokRdPwwBl2QwrF4p YoAkEKDuNEuAav72inc9yKvBQIiGTj8eb33TNIzlr/cmLuM/+yUUzxu6lLStQ6DlSv5rjwguC 0rwXVvz1gOUzcS08z7KNTRg5LbzulTZVhbp4ws1Iogo5gt5quN7tz06y+630pX/Eb36cfiSSH 9N7S+5Cg/cmTuHo5qHSLJj4h8c9I/T7lpWJXGj+xwqhgcn7cyCBrocVxxh0NgxbLJhZMKzUAV zSQ8cIUsdn7VonceBhcj5/Q4X4SLc9K61n0YKF9YDaNpOmQpxwFElvspCwKft2/IK0xUMlkOx l2PywUDcKAcYw7qQF+8+2ON3xWX6bnBYTaO2X/UcXDnFoAH9Hm6HMALA/1HoBPvyJOKO/ZDyi NVqdTpwHWnbXKzvzE0ck0hDHfbrIONYQGt/mSYo2CMFDaijAWXQZ3pAg5scSslx9k6be4rr6P B3FXJ3tfGJJPCV5XEDB9g3nQIkzXAL8ijxN6tdgOAYCVbf6HQsQT6Dw++3CGRCZOip8QZzTn5 epXt3TwrHth5ZZwujwvg+5SNDjE/Ea7b/51dNRsKA01Gmu/M2hPp56kFFUyxcUsyG1+vlturZ StGOAIao+ELb2etZtxauo4pVY+DD/ztq+XnHkeMaUsOXTsRjcbeBJxmUGpzAD6x85kcmgsw6j XDH5afpdFyY+4dodYvfYqkHfmZag02POEmWGxG5717sQL0anhlSlHEEzL9xkpe/a1URF7hE23 ovYE3rTmSHF30CyDPoloihNC3uDKyJk5h70JDDS2VipKvmNfnp/dO1vyPhi1dCqZJ4Wp/MGN9 hwGWC2FpP5NtJN9tMeO6qFTJaUY0+3Y4DHDk3MMPLbDSPqXeT2VLkqjuHhzN2eZN3U/G+htNc /HGLYg/KKNXrhc6r1+xRrHT5M3FEiGUOF8HUyfXwSbUxmOj7wK7pfAN0/zbtZmg3POQQ7ga9K D+SOL57NJNU24ALiSVFAdecUtgw7987yCmBIDVZMiNZQFSoDahD+IzYdIFr3T0445vCoZ4TQS vgAhqOGsIwnpktu6+E4ChvoHx/bWRewDCcJCe1qTkccPwqoAu7E4XBkOA4UT9hf6KhqL/TDBd lF6R3UD6QhIHaNKVJVelT0xG/QmLjvwNYP6B0IGhAGWNFnm7TaSAYSF0t5XOPyf+1bG6nWAk4 FJ0hVOF7qew/06Ql5r/A1Q1ogdoOFT6SuzqZR5743VA8xtQJGrvhn1fl/L4V0xd9jJ3lU= Subject: Re: [Cake] [CAKE] Rate is much lower than expected - CPU load is higher than expected X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2020 16:08:08 -0000 Hi Jonathan, > On Jun 23, 2020, at 17:21, Jonathan Morton = wrote: >=20 >> On 23 Jun, 2020, at 5:41 pm, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: >>=20 >> Right, well if you're not running out of CPU I guess it could be a >> timing issue. The CAKE shaper relies on accurate timestamps and the >> qdisc watchdog timer to schedule the transmission of packets. A = loaded >> system can simply miss deadlines, which would be consistent with the >> behaviour you're seeing. >>=20 >> In fact, when looking into this a bit more, I came across this commit >> that seemed to observe the same behaviour in sch_fq: >> https://git.kernel.org/torvalds/c/fefa569a9d4b >>=20 >> So I guess we could try to do something similar in CAKE. >=20 > Actually, we already do. The first version of Cake's shaper was based = closely on the one in sch_fq at the time, and I modified it after = noticing that it had a very limited maximum throughput when timer = resolution was poor (eg. at 1kHz on an old PC without HPET hardware, we = could only get 1k pps). Now, any late timer event will result in a = burst being issued to catch up with the proper schedule. The only time = that wouldn't work is if the queue is empty. This nicely and effortlessly explains why cake unlike = HTB+fq_codel maintains the set bandwidth better under CPU load (but then = these burst also increase latency under load a bit more; then again = again, we had to make the burst buffering for HTB configurable so it = would not be as bad in dropping bandwidth on the floor). But I assume = that you bound the bursts somehow, do you remember your bust sizing = method by chance? (For HTB/TBF sqm now simply allows the user to = configure a maximum burst service time im microseconds, that at least = allows to make a conscious trade-off). >=20 > If the patches currently being trialled are not sufficient, then = perhaps we could try something counter-intuitive: switch on "flows" = instead of "flowblind", and enable the ack-filter. That should result = in fewer small packets to process, as the ack-filter will coalesce some = acks, especially under load. It might also help to select "satellite" = AQM parameters, reducing the amount of processing needed at that layer. >=20 > - Jonathan Morton >=20 > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake