From: Dave Taht <dave.taht@gmail.com>
To: libreqos <libreqos@lists.bufferbloat.net>,
bloat <bloat@lists.bufferbloat.net>,
cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>
Subject: [Cerowrt-devel] really lovely live plots of bandwidth, queue depth, marks and drops in libreqos
Date: Fri, 6 Jan 2023 20:13:55 -0800 [thread overview]
Message-ID: <CAA93jw4L3qVwP81TWdE4vjcY7_OppYXxpX-UGyiRwK0RDq94yw@mail.gmail.com> (raw)
Wearing my theorist hat... and looking at all the ISP plans
https://payne.taht.net is now emulating.... (click on bandwidth test,
then a plan)
I had never, actually, seen in detail, how cake and fq_codel actually
behave at this range of "plans", starting 2011 with packet captures,
and ns2/ns3 emulations, and mostly working with devices that were
barely capable of pushing 100Mbit, gradually moving up to 1Gbit by
2015 or so. It originally took weeks to get through the packet
captures, then hours to get through and analyze a full range of flent
tests... I'd heard rumors of people pushing cake past 40Gbit, but not
seen anything for myself...
... and now, using herbert's latest rust tooling and his "bifrost" XDP
bridge... and the ebpf pping code with so many contributors... I can
devise a test and watch the results in real time, at a 30ms sample
rate, sufficient, to see slow start, web traffic, voip, and/or other
misbehaviors....[1]
To see a shaped cake transparent middlebox *pushing* 10Gbits
successfully (the theory should scale, but cpu requirements at the
time I stopped working on cake (about 5 years ago) were too much to
test with) as I just did just now on a mere 16 core box, was really
amazing. Being able to *measure* real 10Gbit traffic while only eating
30% of one of those cores, is also amazing.
Our debloated future looks brighter every day. The (GPLv2) code for
LibreQos - continues to evolve. Please join in at:
https://github.com/LibreQoE - In particular I'd like to find
someone(s) with rust and/or python experience to help out? And does
anyone have 2.5gbit box they could try? I'm pretty sure a pretty
pedestrian, arm box, should be able to run this at 2.5Gbit, if
xdp/ebpf are available on it. Anyone have tests to suggest?
[1] and so far, the only misbehaviors I've spotted are related to a
syn timeout on one of the more gnarly tests
--
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-6981366665607352320-FXtz
Dave Täht CEO, TekLibre, LLC
reply other threads:[~2023-01-07 4:14 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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/cerowrt-devel.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAA93jw4L3qVwP81TWdE4vjcY7_OppYXxpX-UGyiRwK0RDq94yw@mail.gmail.com \
--to=dave.taht@gmail.com \
--cc=bloat@lists.bufferbloat.net \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=libreqos@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