From: Sebastian Moeller <moeller0@gmx.de>
To: Jonathan Morton <chromatix99@gmail.com>
Cc: Christoph Paasch <cpaasch@apple.com>, Rpm <rpm@lists.bufferbloat.net>
Subject: Re: [Rpm] Alternate definitions of "working condition" - unnecessary?
Date: Mon, 11 Oct 2021 12:03:35 +0200 [thread overview]
Message-ID: <C4467B7E-A174-4B25-B5D3-A3AD1F988286@gmx.de> (raw)
In-Reply-To: <444988D6-11E3-41FB-BDF2-E94C1123C216@gmail.com>
Hi Jonathan,
> On Oct 11, 2021, at 11:01, Jonathan Morton <chromatix99@gmail.com> wrote:
>
>> On 11 Oct, 2021, at 10:31 am, Sebastian Moeller <moeller0@gmx.de> wrote:
>>
>>>> (I am also wondering how reducing the default number of
>>>> sub-queues from 1024 to 128 behaves on the background of the
>>>> birthday paradox).
>>>
>>> Not sure where the 128 comes from ?
>>
>> See above:
>> [ sched: FQ_CODEL qlength: 0/128 ]
>> but I might simply be misinterpreting the number here…
>
> Yes, I think so.
Thanks.
> This probably refers to the maximum number of packets that can be enqueued in total, and has no relation to the number of hash buckets that may or may not be present - though obviously you can't have more occupied queues than there are enqueued packets.
Do you have a link to the fq_codel source code for macos/iOS that I could use he next time to first do some research, by any chance?
Best Regards
Sebastian
>
> - Jonathan Morton
next prev parent reply other threads:[~2021-10-11 10:03 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-06 19:11 Rich Brown
2021-10-06 20:36 ` Jonathan Foulkes
2021-10-07 16:40 ` Toke Høiland-Jørgensen
2021-10-07 18:49 ` Dave Taht
2021-10-08 17:51 ` Toke Høiland-Jørgensen
2021-10-07 21:39 ` Rich Brown
2021-10-06 21:22 ` Dave Taht
2021-10-06 23:18 ` Jonathan Morton
2021-10-07 0:11 ` Christoph Paasch
2021-10-07 10:29 ` Jonathan Morton
2021-10-07 15:44 ` [Rpm] apple's fq_"codel" implementation Dave Taht
2021-10-07 10:30 ` [Rpm] Alternate definitions of "working condition" - unnecessary? Sebastian Moeller
2021-10-08 0:33 ` Jonathan Morton
2021-10-08 23:32 ` Christoph Paasch
2021-10-11 7:31 ` Sebastian Moeller
2021-10-11 9:01 ` Jonathan Morton
2021-10-11 10:03 ` Sebastian Moeller [this message]
2021-10-11 17:34 ` Christoph Paasch
2021-10-12 10:23 ` Sebastian Moeller
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/rpm.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=C4467B7E-A174-4B25-B5D3-A3AD1F988286@gmx.de \
--to=moeller0@gmx.de \
--cc=chromatix99@gmail.com \
--cc=cpaasch@apple.com \
--cc=rpm@lists.bufferbloat.net \
/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