[Bloat] WSL2 + fq_codel

[Bloat] WSL2 + fq_codel

[Dave Taht]

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

...

CONFIG_NET_SCH_DEFAULT=y
CONFIG_DEFAULT_FQ_CODEL=y
# CONFIG_DEFAULT_PFIFO_FAST is not set
CONFIG_DEFAULT_NET_SCH="fq_codel"


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

Re: [Bloat] WSL2 + fq_codel

[Michael Richardson]

[-- Attachment #1.1: Type: text/plain, Size: 1008 bytes --]


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.


[-- Attachment #1.2: Signature --]
[-- Type: text/plain, Size: 242 bytes --]

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 511 bytes --]

Re: [Bloat] WSL2 + fq_codel

[Stephen Hemminger]

[-- Attachment #1: Type: text/plain, Size: 1256 bytes --]

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.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Bloat] WSL2 + fq_codel

[Dave Taht]

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

Re: [Bloat] WSL2 + fq_codel

[Maximilian Bachl]

[-- Attachment #1: Type: text/plain, Size: 3394 bytes --]

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

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
>

[-- Attachment #2: Type: text/html, Size: 4740 bytes --]

Re: [Bloat] WSL2 + fq_codel

[Stephen Hemminger]

[-- Attachment #1: Type: text/plain, Size: 3662 bytes --]

Should be whatever the Linux distro default is. Most people use Ubuntu

On Mon, Feb 27, 2023, 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
>
> 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
>>
>

[-- Attachment #2: Type: text/html, Size: 5443 bytes --]

Re: [Bloat] WSL2 + fq_codel

[Dave Taht]

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