General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Dave Taht <dave.taht@gmail.com>
To: Maximilian Bachl <maximilian.bachl@gmail.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>,
	 Michael Richardson via Bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] WSL2 + fq_codel
Date: Mon, 27 Feb 2023 15:36:14 -0800	[thread overview]
Message-ID: <CAA93jw7mhFiCsGk8MKcid04cdG5ygkCpyp3RGDvxeWzvS=cuWw@mail.gmail.com> (raw)
In-Reply-To: <CAEXAmbvoZu8m0VnC4eewcddeCH=gwZm7RjJ-T8iNJcG3wLuzFA@mail.gmail.com>

On Mon, Feb 27, 2023 at 4:11 AM Maximilian Bachl
<maximilian.bachl@gmail.com> wrote:
>
> Yes, the default interface of WSL2 seems to use fq_codel:
>
> $ tc qdisc show dev eth0
> qdisc mq 0: root
> qdisc fq_codel 0: parent :8 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
> qdisc fq_codel 0: parent :7 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
> qdisc fq_codel 0: parent :6 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
> qdisc fq_codel 0: parent :5 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
> qdisc fq_codel 0: parent :4 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
> qdisc fq_codel 0: parent :3 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
> qdisc fq_codel 0: parent :2 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn
> qdisc fq_codel 0: parent :1 limit 10240p flows 1024 quantum 1514 target 5.0ms interval 100.0ms memory_limit 32Mb ecn

yay! Is there any sign that it is actually working as designed here
(load it up with 16+ flows, see if you had drops or reschedules via tc
-s qdisc show)

> On Sat, Feb 25, 2023 at 11:07 PM Dave Taht via Bloat <bloat@lists.bufferbloat.net> wrote:
>>
>> On Sat, Feb 25, 2023 at 12:54 PM Stephen Hemminger
>> <stephen@networkplumber.org> wrote:
>> >
>> > On Sat, 25 Feb 2023 15:37:02 -0500
>> > Michael Richardson via Bloat <bloat@lists.bufferbloat.net> wrote:
>> >
>> > > Dave Taht via Bloat <bloat@lists.bufferbloat.net> wrote:
>> > >     > I so want to believe... I so want to believe... can anyone confirm?
>> > >
>> > >     > https://raw.githubusercontent.com/microsoft/WSL2-Linux-Kernel/linux-msft-wsl-5.15.y/Microsoft/config-wsl
>> > >
>> > > But, AFAIK, WSL isn't a kernel.  It's an implementation of the Linux ABI on
>> > > top of Windows service(s).  If you told me that they build some of it from
>> > > actual Linux kernel sources, I'd believe you.  (Rather like User-Mode-Linux)
>> > >
>> > > If you told me that they have a kernel that they build for when they actually
>> > > spin up an actual VM (such as to run containers) that would also be unsurprising.
>> > >
>> > >     > ...
>> > >
>> > >     > CONFIG_NET_SCH_DEFAULT=y
>> > >     > CONFIG_DEFAULT_FQ_CODEL=y
>> > >     > # CONFIG_DEFAULT_PFIFO_FAST is not set
>> > >     > CONFIG_DEFAULT_NET_SCH="fq_codel"
>> > >
>> > > It would be nice if the billion windows desktops started doing
>> > > something better, but I don't think it will help observed latency.
>> > > The real question is what the default schedule for the default Azure Linux VM
>> > > is.
>> > >
>> >
>> > I think WSL2 is actually a full Linux VM running in Hyper-V.
>>
>> Yes, it is. But it is kind of unknown how the underlying network
>> interface is behaving in this case, as well as what the actual default
>> qdisc is, and this not just a random gist. It was VERY exciting to see
>> that gist go by...
>>
>> are there no windows users on this list? :/ We long ago should have
>> pursued at least flent, and a TCP_INFO equivalent sampling method for
>> windows. The closest thing we have for windows is the rust-based:
>> https://github.com/Zoxc/crusader
>>
>> --
>> A pithy note on VOQs vs SQM: https://blog.cerowrt.org/post/juniper/
>> Dave Täht CEO, TekLibre, LLC
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat



-- 
A pithy note on VOQs vs SQM: https://blog.cerowrt.org/post/juniper/
Dave Täht CEO, TekLibre, LLC

      parent reply	other threads:[~2023-02-27 23:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-25 18:54 Dave Taht
2023-02-25 20:37 ` Michael Richardson
2023-02-25 20:54   ` Stephen Hemminger
2023-02-25 22:07     ` Dave Taht
2023-02-27 12:10       ` Maximilian Bachl
2023-02-27 23:32         ` Stephen Hemminger
2023-02-27 23:36         ` Dave Taht [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/bloat.lists.bufferbloat.net/

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

  git send-email \
    --in-reply-to='CAA93jw7mhFiCsGk8MKcid04cdG5ygkCpyp3RGDvxeWzvS=cuWw@mail.gmail.com' \
    --to=dave.taht@gmail.com \
    --cc=bloat@lists.bufferbloat.net \
    --cc=maximilian.bachl@gmail.com \
    --cc=stephen@networkplumber.org \
    /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