Many ISPs need the kinds of quality shaping cake can do
 help / color / mirror / Atom feed
From: Thorsten Glaser <t.glaser@tarent.de>
To: Dave Taht <dave.taht@gmail.com>
Cc: libreqos@lists.bufferbloat.net
Subject: Re: [LibreQoS] qdisc_watchdog_schedule_range_ns granularity
Date: Sun, 23 Oct 2022 01:39:35 +0200 (CEST)	[thread overview]
Message-ID: <12c7ec6-dce1-4411-98b6-fecd4e5c46e9@tarent.de> (raw)
In-Reply-To: <CAA93jw5r4bayK-PLSBfaqNxhaNoZcN9x2800YRjbpqhg04r=Vw@mail.gmail.com>

On Sat, 22 Oct 2022, Dave Taht wrote:

> I'm rather interested in your work because I don't understand how well
> cake's shaper interacts with all the other loads, neither, htb. We're

Interesting. Do keep in mind that this experimental qdisc will not
become a generally useful one; rather one that attempts to mirror
what an L4S slice in the 5G network does for *one* UE. We’re using
this, on Intel NUCs acting as routers, so people can develop/test
and possibly fine-tune their final application algorithms that will
then be useful out in the field, where you don’t have this much insight
or debugging info.

> hacking on this, running at speeds (10gbps) that are hard to measure

OK, that’s tricky indeed.

> at... with tools that don't exist yet, with kernel dependencies we
> don't understand.

Hey, that’s also where I am ;-)

> How are you measuring, below? ebpf?

No, relayfs again. The commit to add that was rather small even:

> > See commit 2a61f1ea843dc767d291074eee9b2f1b8d3992a7 in
> > git@github.com:tarent/sch_jens.git branch master for the

Basically save away the time we expect the watchdog to call us,
then compare that with now the next time we’re called.

As for packages’ qdisc latency, same as fq_codel basically, just
(now) in ns.

The model here is: extralatency is simulated “before” the packets
enter the qdisc, so while they’re put into the FIFO they are not
considered arrived there yet. That’s (again) to help debugging the
end user algorithms (turns out that BBR2 is no worse than L4S-based
things at very small latencies).

Then we have the normal queue delay, controlled by the arrival time
of the packet (if extralatency is used, with that added) and its
eventual departure time, no earlier than the previous packet’s
departure plus ns_per_byte times its size. We ECN CE mark based on
that as well, which (and the dropping of too old packets) is what
Ericsson tells us is what the RAN does.

I have absolutely no idea how to even begin to use eBPF, tbh…
I’ve never encountered this Linux-specific tech before.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

                        ****************************************************
/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against      Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also,     https://www.tarent.de/newsletter
╱ ╲ header encryption!
                        ****************************************************

      reply	other threads:[~2022-10-22 23:39 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <c4a1d4ff-82eb-82c9-619e-37c18b41a017@tarent.de>
     [not found] ` <44a7e82b-0fe9-d6ba-ee12-02dfa4980966@gmail.com>
     [not found]   ` <a896ad54-297b-c55e-1d34-14ab26949ab6@tarent.de>
     [not found]     ` <2b195a93-a88b-33c2-661a-85fa8513c063@gmail.com>
     [not found]       ` <9c1bb95b-3933-2b33-b8c6-ddefc8459afa@tarent.de>
2022-10-22 23:04         ` Dave Taht
2022-10-22 23:39           ` Thorsten Glaser [this message]

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/libreqos.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=12c7ec6-dce1-4411-98b6-fecd4e5c46e9@tarent.de \
    --to=t.glaser@tarent.de \
    --cc=dave.taht@gmail.com \
    --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