From: Jonathan Morton <chromatix99@gmail.com>
To: "Toke Høiland-Jørgensen" <toke@redhat.com>
Cc: Jose Blanquicet <blanquicet@gmail.com>,
cake@lists.bufferbloat.net,
marco maniezzo <marco.maniezzo@gmail.com>
Subject: Re: [Cake] [CAKE] Rate is much lower than expected - CPU load is higher than expected
Date: Tue, 23 Jun 2020 18:21:54 +0300 [thread overview]
Message-ID: <8959B7A6-0B20-4812-BC9D-812DD4F3BCC4@gmail.com> (raw)
In-Reply-To: <87lfkdrgip.fsf@toke.dk>
> On 23 Jun, 2020, at 5:41 pm, Toke Høiland-Jørgensen <toke@redhat.com> wrote:
>
> 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.
>
> 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
>
> So I guess we could try to do something similar in CAKE.
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.
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.
- Jonathan Morton
next prev parent reply other threads:[~2020-06-23 15:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-22 13:10 Jose Blanquicet
2020-06-22 14:25 ` Y
2020-06-22 15:47 ` Toke Høiland-Jørgensen
2020-06-23 13:05 ` Jose Blanquicet
2020-06-23 14:41 ` Toke Høiland-Jørgensen
2020-06-23 15:21 ` Jonathan Morton [this message]
2020-06-23 16:08 ` Sebastian Moeller
2020-06-23 16:25 ` Jonathan Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/cake.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8959B7A6-0B20-4812-BC9D-812DD4F3BCC4@gmail.com \
--to=chromatix99@gmail.com \
--cc=blanquicet@gmail.com \
--cc=cake@lists.bufferbloat.net \
--cc=marco.maniezzo@gmail.com \
--cc=toke@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox