<font face="arial" size="3"><p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">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.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">That actually has a significant effect on "queue depth".  Please don't call it "interference", because no packet corruption happens.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">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.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">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.</p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;"> </p>
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">-----Original Message-----<br />From: "Jonathan Morton" <chromatix99@gmail.com><br />Sent: Sunday, February 10, 2019 7:38am<br />To: "Adrian Popescu" <adriannnpopescu@gmail.com><br />Cc: make-wifi-fast@lists.bufferbloat.net<br />Subject: Re: [Make-wifi-fast] bloated ath10k<br /><br /></p>
<div id="SafeStyles1549824769">
<p style="margin:0;padding:0;font-family: arial; font-size: 12pt; overflow-wrap: break-word;">> On 10 Feb, 2019, at 2:24 pm, Adrian Popescu <adriannnpopescu@gmail.com> wrote:<br />> <br />> 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.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />If low latency is mission critical, though - just run a wire.<br /><br /> - Jonathan Morton<br /><br />_______________________________________________<br />Make-wifi-fast mailing list<br />Make-wifi-fast@lists.bufferbloat.net<br />https://lists.bufferbloat.net/listinfo/make-wifi-fast</p>
</div></font>