[Make-wifi-fast] bloated ath10k

[Make-wifi-fast] bloated ath10k

[Adrian Popescu]

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

Hello,

Wifi still seems to be bloated in openwrt. Some Windows clients and Android
clients are still bloated.

Machines connected via wires seem to experience bufferbloat which is orders
of magnitude lower than wifi. ath9k seems to have good performance and low
latency from what I can see. ath10k seems to be pretty bad.

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.

What can we do to improve the latency of wifi networks? What's the status
of the air fairness patches? Can we do something to reduce the amount of
buffering for ath10k?

Could we do something on the AP side to reduce or mitigate bloat
experienced by the stations?

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

Re: [Make-wifi-fast] bloated ath10k

[Jonathan Morton]

> 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

Re: [Make-wifi-fast] bloated ath10k

[Adrian Popescu]

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

Running a wire isn't an option for devices which don't have ethernet ports.

I'll try to run some tests with flent to figure out what's happening. A
constant latency of 20-30 ms isn't a big deal. The spikes which cause
stuttering during a voice or video call are the real problem. The
stuttering may not have been caused by these spikes.

It seems that these routers don't have enough power to do traffic shaping,
NAT and to forward hundreds of mbps of data. It might be interesting to
compare the idle latency with the latency under load. I've also considered
running some tests with mac80211_hwsim. mac80211_hwsim may not provide the
option to simulate a deep buffer like the ath10k one and may not be as
relevant.



On Sun, Feb 10, 2019 at 2:38 PM Jonathan Morton <chromatix99@gmail.com>
wrote:

> > 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
>
>

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

Re: [Make-wifi-fast] bloated ath10k

[David P. Reed]

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


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

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

Re: [Make-wifi-fast] bloated ath10k

[Bob McMahon]

[-- 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 --]

Re: [Make-wifi-fast] bloated ath10k

[Bob McMahon]

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

Also, way off topic but the data center switch architects have proposed
something called HULL.

 https://people.csail.mit.edu/alizadeh/papers/hull-nsdi12.pdf

One model of the forwarding plane is that the chip firmware is indeed part
of the forwarding and the spectrum/AP provides the mesh or "switching
fabric."  It's somewhat similar to how data center switches are designed.
 In that context a STA, besides minimizing it's processing delay, may be
able to do the following interesting things:

   1. If RX queues are "full" (or hit the phantom queue depth) set the CE
   bit to signal TCP
   2. If TX queues are "full" and a standing queue (per bloat) is behind
   it, then drop.  If not, then advantage the air access via adaptive EDCA,
   e.g. reduce the AIFS (within the limits of the standards)  An AP might want
   to advertise a somewhat larger AIFS so a STA reducing its for a brief
   period will achieve the arbitration goals.

As a side note, we've done a lot of timing work in iperf 2.0.13 to help
fault isolate latency issues.  It works best if the device realtime clocks
are synchronized, e.g. to a GPS disciplined OCXO using PTP.   We also added
TCP connect times to monitor the 3WHS as well as trip times, timing the
data xfer phase.   Iperf 2.0.13 has been picked up by many distributions.

https://sourceforge.net/projects/iperf2/
https://sourceforge.net/projects/iperf2/files/Iperf%202.0.13%20Enhancements.pdf/download

Thoughts welcomed and appreciated

Bob

On Mon, Feb 11, 2019 at 7:48 AM Bob McMahon <bob.mcmahon@broadcom.com>
wrote:

> 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: 7367 bytes --]

Re: [Make-wifi-fast] bloated ath10k

[David P. Reed]

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


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@broadcom.com>
Sent: Sunday, February 10, 2019 9:18pm
To: "David P. Reed" <dpreed@deepplum.com>
Cc: "Jonathan Morton" <chromatix99@gmail.com>, "Make-Wifi-fast" <make-wifi-fast@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/ ]( http://kumunetworks.com/ )
Bob


On Mon, Feb 11, 2019 at 12:30 AM David P. Reed <[ dpreed@deepplum.com ]( mailto: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 ]( mailto:chromatix99@gmail.com )>
Sent: Sunday, February 10, 2019 7:38am
To: "Adrian Popescu" <[ adriannnpopescu@gmail.com ]( mailto:adriannnpopescu@gmail.com )>
Cc: [ make-wifi-fast@lists.bufferbloat.net ]( mailto: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 ]( mailto: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 ]( mailto:Make-wifi-fast@lists.bufferbloat.net )
[ https://lists.bufferbloat.net/listinfo/make-wifi-fast ]( https://lists.bufferbloat.net/listinfo/make-wifi-fast )_______________________________________________
 Make-wifi-fast mailing list
[ Make-wifi-fast@lists.bufferbloat.net ]( mailto:Make-wifi-fast@lists.bufferbloat.net )
[ https://lists.bufferbloat.net/listinfo/make-wifi-fast ]( https://lists.bufferbloat.net/listinfo/make-wifi-fast )

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

Re: [Make-wifi-fast] bloated ath10k

[Bob McMahon]

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

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@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@broadcom.com>
> Sent: Sunday, February 10, 2019 9:18pm
> To: "David P. Reed" <dpreed@deepplum.com>
> Cc: "Jonathan Morton" <chromatix99@gmail.com>, "Make-Wifi-fast" <
> make-wifi-fast@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@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: 11002 bytes --]