--
You received this message because you are subscribed to the Google Groups "BBR Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bbr-dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bbr-dev/CAA93jw6yJU10wh9ajqX4yW2AvnJPStyWAAcV4%2BoQ8wSGsJgKZA%40mail.gmail.com.
Thanks for sharing this. Curious about how the xTSQ value can be set? Can it be done with sysctl?
We continue our analysis by using the ms-version of TSQ patch, which enables the tune of the TSQ size allowing each TCP variant to enqueue more than 1 ms of data at the current TCP rate. In particular, we allow to enqueue the equivalent of x ms of data, naming each test xTSQ, with x being an integer value. It is important to notice that this patch has been included in the Linux kernel mainline, and each Wi-Fi driver can now set the desired xTSQ value.
To view this discussion on the web visit https://groups.google.com/d/msgid/bbr-dev/CAHb6LvrK_exkt_rbukYkF4_hwPXyy9T%2BZNGzdK79x91RrK49Mg%40mail.gmail.com.
On Tue, 22 Nov 2022, Bob McMahon via Make-wifi-fast wrote:
> Finally, many (most?) APs are forwarding and feeding packets at at the
> hardware level so not sure that the linux stack matters as much for an AP
> based analysis, particularly when considering multi user transmissions,
> i.e. multiple WiFi clients are active and sharing TXOPs.
APs forward packets within the switch at the hardware level, but the radios have
to go through the CPU, so any wired <-> wireless needs to go through the CPU,
and I would be incredibly surprised if the wifi chips did wireless <-> wireless
routing at the hardware level.
David Lang
sorry, when I was saying 'the cpu', I was meaning the main one running linux,
not something that's part of the wifi chipset.
I would be very surprised if the wifi chipset is doing any packet routing, as
opposed to just sending the packets to the main processor.
Remember, the common case isn't forwarding from one wifi device to another, it's
moving between wifi devices and the wired uplink.
David Lang
Neal Cardwell via Bloat <bl...@lists.bufferbloat.net> writes:
> On Tue, Nov 22, 2022 at 2:43 PM 'Bob McMahon' via BBR Development <
> bbr...@googlegroups.com> wrote:
>
>> Thanks for sharing this. Curious about how the xTSQ value can be set? Can
>> it be done with sysctl?
>>
>> *We continue our analysis by using the ms-version of TSQ patch, which
>> enables the tune of the TSQ size allowing each TCP variant to enqueue more
>> than 1 ms of data at the current TCP rate. In particular, we allow to
>> enqueue the equivalent of x ms of data, naming each test xTSQ, with x being
>> an integer value. It is important to notice that this patch has been
>> included in the Linux kernel mainline, and each Wi-Fi driver can now set
>> the desired xTSQ value**.*
>>
>
> I believe they are setting the xTSQ value using the sk_pacing_shift field,
> which was added here:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3a9b76fd0db9f0d426533f96a68a62a58753a51e
>
> AFAIK the intent is only for drivers to set that, and there's no sysctl for
> that, but of course you could add a sysctl for testing if you wanted.
> :-)
Yup, indeed this is what mac80211 fiddles with:
https://elixir.bootlin.com/linux/latest/source/net/mac80211/main.c#L739
https://elixir.bootlin.com/linux/latest/source/net/mac80211/tx.c#L4156
AFAICT, no in-tree drivers override the value set by mac80211.
I believe the tests in that paper were conducted with this series
applied:
https://lore.kernel.org/all/20180105113256.14835...@gmail.com/
-Toke
Bob McMahon <bob.m...@broadcom.com> writes:
> Does the TSQ code honor no-aggregation per voice access class or
> TCP_NODELAY where the app making the socket write calls knows that the WiFi
> aggregation isn't likely helpful? Sorry, my Linux stack expertise is quite
> limited.
TSQ only influences the buffering in the TCP layer. The WiFi stack will
still limit aggregation using its own logic (I think it turns it off
entirely for voice?). TCP_NODELAY is also orthogonal to TSQ; TSQ only
kicks in when there's a bunch of data buffered, in which case
TCP_NODELAY has no effect...
-Toke
Hi dev group guys,
I need to use sysctl to set ms value for net.ipv4.tcp_limit_output_ms .
The TSQ patch attached is not working or letting me do that . I am on linux 5.13.12
Manually changing tx_sk_pacing_shift = 7; variable in main.c needs to recompile kernel everytime…
I need to have sysctl to control the ms value , to set 2TSQ,4TSQ,8TSQ etc for my wifi chipset.
I will be thankful if anyone can help me in it.
Rgds,
Ahsan
To view this discussion on the web visit https://groups.google.com/d/msgid/bbr-dev/CADVnQyn9OSxPcF2JsUHdiWLTvAAdN5vs1uyiRBL0AS8yH8niYw%40mail.gmail.com.