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 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" > Sent: Sunday, February 10, 2019 7:38am > To: "Adrian Popescu" > Cc: make-wifi-fast@lists.bufferbloat.net > Subject: Re: [Make-wifi-fast] bloated ath10k > > > On 10 Feb, 2019, at 2:24 pm, Adrian Popescu > 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