[Make-wifi-fast] bloated ath10k

Mon Feb 11 13:07:37 EST 2019

Hi David,

Thanks for the discussion and tolerating hearing what you already know.

Per Jaffe, TCP can't be optimized to achieve maximum network power (avg
throughput / latency) because an end host  (or TCP end) only has only local
knowledge.  I think that's why things like HULL are setting the CE bit and
why we have so many TCP control loops none of which can determine the true
"near congestion point."  With wireless links, the STAs aren't limited to
local knowledge because their PHYs are always listening to the medium.  I
think this helps chip fw towards the ability to detect the input rate as
exceeding the possible service rate (as defined by "congestion" and/or
"free spectrum" - whatever those terms mean as neither are related to
physics. ;)  If this is the case, the chip fw can determine, and may be
able to predict, with STA state when the "queued traffic on LAN reached
threshold."

Per 802.11ax the AP will need to have virtual output queues to work with
downlink OFDMA.  Those transmits are truly "in parallel" which requires the
multiple queues on the AP.  So I don't perceive the two queues feeding one
queue "engineering phenomena" lasting forever.

I'm no mesh expert but it does seem suboptimal that a transmit from STA A
to STA B needs to be forwarded by an AP if STA B received the energy from A
at an SINR that it allows it to decode the packet.  In this case, the ack
could come from B to A directly and the AP could drop what it heard.  No
ack from the real destination, then the AP forwards.

Though with 802.11ax, it's all centered around the AP for scheduling , i.e.
all transmits even on STAs are "triggered" and the AP sets the transmit
powers so uplink OFDMA works.    I'm not sure how well 802.11ax plays with
mesh.

Just some more random thoughts and thanks again for the discussion.

Bob

On Mon, Feb 11, 2019 at 8:17 PM David P. Reed <dpreed at deepplum.com> wrote:

> Bob - I was focusing on the standard Listen-Before-Talk CSMA MAC approach
> in the current 802.11 through the ac variant. 802.11ax is, of course, a
> whole different MAC layer, and its queuing management issues for IP
> end-to-end congestion management will be different.
>
>
>
> It seems likely to me that by being more oriented around AP-centered
> scheduling it will behave more like a single shared queue without fairness
> at the IP flow level. Since bufferbloat is essentially caused by queuing
> below the IP layer without providing timely feedback to the IP endpoints, I
> don't think 802.11ax can fix bufferbloat by itself. Some kind of "queued
> traffic on LAN reached threshold" message needs to be made available to the
> IP forwarding mechanism in each MAC STA and AP in 802.11ax in order to
> mitigate lag under load. And IP flow-level fairness needs to be
> implementable by the IP forwarding layet (ideally collectively among all
> sharing the up channel, which AP scheduling of the uplink can achieve,
> maybe).
>
>
>
> I was peripherally involved in the "self-cancellation" PHY research at MIT
> at one point, and I know of the other experiments out in the Bay Area. It
> does look promising, but the issue I was pointing out is still there: if
> STA A and STA B send to each other, the AP-STA links are still a shared
> queue that can transmit only one packet at a time. So while there is some
> simultaneity from the PHY level, there are still two uplink queues feeding
> into a single downlink queue in the paths between A and B when there is an
> AP involved as an intermediary. Thats what I was pointing out as the
> complex queue-dynamics issue.
>
>
>
> Glad to hear that full duplex is being explored for commercial use now. It
> will certainly double the capacity using the same airtime for twice as
> much. I won't spend time pointing out that there are even better
> opportunities that get more than 2x for an N-node WLAN, by going to
> physical level repeaters. (but that's still all theory, not reduced to
> practice in labs, except a little bit).
>
>
>
>
>
> -----Original Message-----
> From: "Bob McMahon" <bob.mcmahon at broadcom.com>
> Sent: Sunday, February 10, 2019 9:18pm
> To: "David P. Reed" <dpreed at deepplum.com>
> Cc: "Jonathan Morton" <chromatix99 at gmail.com>, "Make-Wifi-fast" <
> make-wifi-fast at lists.bufferbloat.net>
> Subject: Re: [Make-wifi-fast] bloated ath10k
>
> 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 at 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 at gmail.com>
>> Sent: Sunday, February 10, 2019 7:38am
>> To: "Adrian Popescu" <adriannnpopescu at gmail.com>
>> Cc: make-wifi-fast at lists.bufferbloat.net
>> Subject: Re: [Make-wifi-fast] bloated ath10k
>>
>> > On 10 Feb, 2019, at 2:24 pm, Adrian Popescu <adriannnpopescu at 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 at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>> _______________________________________________
>> Make-wifi-fast mailing list
>> Make-wifi-fast at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/make-wifi-fast/attachments/20190211/7494725b/attachment.html>