On Thu, Oct 14, 2021 at 2:44 PM Toke Høiland-Jørgensen <[email protected]> wrote: > > Dave Taht <[email protected]> writes: > > > weirdly enough, my gmail account has not received anything from netdev > > since oct 11. > > You're not alone in that: > https://lore.kernel.org/netdev/20211014112718.6aed7...@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com/T/#t
ok. One of these years I'll go back to running my own email server full time. > > yes, i think fq_codel will be better, and even the proposed > > too-shallow threshold will make for less of a dent on the internet. > > > > still... I do wish I'd seen this earlier. > > Earlier? You forwarded the patch hours after it was posted... I have a daily search for fq_codel, bufferbloat, etc. I have noticed lately that some mailing list traffic from us is being indexed again. I wish I knew why our lists were not indexed by google. Anyway, lacking being on that thread, it's currently impossible to reply. I would certainly like more to be exploring HFCC - I do agree that a shallow marking threshold is increasingly necessary at rates beyond 10Gbit, and that more would read - https://github.com/heistp/l4s-tests#key-findings before the internet is split into a fast and slow lane. That said, the l4s fq_codel patch is intrinsically fair, which is vastly superior to the dualpi approach. I think that the over-shallow proposed threshold of 50us - the lowest I'd seen to date was 250us! won't work on anything other than bare iron or from a self-local qdisc, and that will lead to the implementation being naturally slow rate on virtualized hosts, but lossless, which would be a win, and for all I know interact well with the fast/slow queue concept. I certainly think bbrv2 needs more testing, as it has always seemed to be a more promising approach than prague. My biggest feedback on the patch so far is I dislike the overload on reporting where the CE came from, and would prefer that l4s_ce be exposed to userspace. We have very little data on actual ce's in the field as it is - conflating the two statistics won't help - I also hate adding anything more to the hot path. And if we have to do it, making sce available as an optional at the same time has the same computational cost. And it still bugs me, very much, that bbrv1 has no rfc3168-like response. Perhaps with some time to work on a coherent reply to this patch and figuring out how to get back on netdev, I can say all that better. Or I can just go back to fixing up my boat. > > -Toke -- Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw Dave Täht CEO, TekLibre, LLC _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
