Re: [Make-wifi-fast] bloated ath10k

[Bob McMahon <bob.mcmahon@broadcom.com>]

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

Just a reminder with 802.11ax uplink OFDMA that STA A and B transmits can
be "concurrent."    Also, there are companies working on full duplex per
self cancellation.  Kumu networks is one

http://kumunetworks.com/

Bob

On Mon, Feb 11, 2019 at 12:30 AM David P. Reed <dpreed@deepplum.com> wrote:

> Side note: between two stations talking through an AP, it's not half
> duplex. It's kind-of quarter-duplex. Each packet between STA A and STA B
> cannot  be concurrent with the subsequent packet from A to B, and both
> transmissions of a packet from B to A.
>
> That actually has a significant effect on "queue depth".  Please don't
> call it "interference", because no packet corruption happens.
>
>
>
> This is why merely fixing the queueing discipline in the AP alone doesn't
> necessarily ameliorate bufferbloat. The queues in the STA's need to be
> managed, too.
>
>
>
> You guys know that implicitly, I know I'm not telling you anything you
> don't know. But this queueing needs to be managed in such a way that the
> backoff in TCP is signaled. That is, packets need to be dropped or marked.
> You can't fix this in the forwarding paths alone.
>
>
>
> -----Original Message-----
> From: "Jonathan Morton" <chromatix99@gmail.com>
> Sent: Sunday, February 10, 2019 7:38am
> To: "Adrian Popescu" <adriannnpopescu@gmail.com>
> Cc: make-wifi-fast@lists.bufferbloat.net
> Subject: Re: [Make-wifi-fast] bloated ath10k
>
> > On 10 Feb, 2019, at 2:24 pm, Adrian Popescu <adriannnpopescu@gmail.com>
> wrote:
> >
> > My attempts to use SQM and codel to reduce wifi bloat didn't seem to get
> me very far. 802.11ac seems more reliable and it seems to be more bloated.
> ath9k can go as low as 3-5 milliseconds. ath10k is usually in the 20-50
> milliseconds range (or more, based on the number of stations). I usually
> test with a single client as I don't expect latency to improve with more
> clients.
>
> Some things are unavoidable when you move to a shared, half-duplex, noisy
> medium like wifi versus a switched, full-duplex, error-free medium like
> Ethernet.
>
> If you're getting 20-50ms under load, then I think things are working
> quite well with wifi. We can wish for better, but not long ago you could be
> looking at multiple seconds in bad cases. At the levels you're now seeing,
> ordinary interactive protocols like DNS and HTTP will work reliably and
> quickly, and even VoIP should be able to cope; you'll likely only really
> notice a problem with online games.
>
> Ath9k has some advantages over ath10k in this area. Its MAC is managed at
> a lower level by the driver, so we have much more control over it when
> trying to debloat. I think we still have more control over ath10k than most
> of the alternatives.
>
> If low latency is mission critical, though - just run a wire.
>
> - Jonathan Morton
>
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast

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