From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp70.iad3a.emailsrvr.com (smtp70.iad3a.emailsrvr.com [173.203.187.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id CC0A53B2A4 for ; Mon, 11 Feb 2019 09:47:09 -0500 (EST) Received: from smtp1.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp1.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 972492E31; Mon, 11 Feb 2019 09:47:09 -0500 (EST) X-SMTPDoctor-Processed: csmtpprox beta Received: from smtp1.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp1.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 921755B20; Mon, 11 Feb 2019 09:47:09 -0500 (EST) Received: from app3.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp1.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 69AF42E31; Mon, 11 Feb 2019 09:47:09 -0500 (EST) X-Sender-Id: dpreed@deepplum.com Received: from app3.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Mon, 11 Feb 2019 09:47:09 -0500 Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app3.wa-webapps.iad3a (Postfix) with ESMTP id 578F0A0042; Mon, 11 Feb 2019 09:47:09 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Mon, 11 Feb 2019 09:47:09 -0500 (EST) X-Auth-ID: dpreed@deepplum.com Date: Mon, 11 Feb 2019 09:47:09 -0500 (EST) From: "David P. Reed" To: "Bob McMahon" Cc: "Jonathan Morton" , "Make-Wifi-fast" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20190211094709000000_75528" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: <3CB198EB-2844-42DB-9E5A-26708BFD7304@gmail.com> <1549825225.478726910@apps.rackspace.com> Message-ID: <1549896429.35521705@apps.rackspace.com> X-Mailer: webmail/16.0.0-RC Subject: Re: [Make-wifi-fast] bloated ath10k X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 14:47:09 -0000 ------=_20190211094709000000_75528 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0ABob - I was focusing on the standard Listen-Before-Talk CSMA MAC approac= h in the current 802.11 through the ac variant. 802.11ax is, of course, a w= hole different MAC layer, and its queuing management issues for IP end-to-e= nd congestion management will be different.=0A =0AIt seems likely to me tha= t 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 buf= ferbloat is essentially caused by queuing below the IP layer without provid= ing timely feedback to the IP endpoints, I don't think 802.11ax can fix buf= ferbloat by itself. Some kind of "queued traffic on LAN reached threshold" = message needs to be made available to the IP forwarding mechanism in each M= AC 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 (ideall= y collectively among all sharing the up channel, which AP scheduling of the= uplink can achieve, maybe).=0A =0AI was peripherally involved in the "self= -cancellation" PHY research at MIT at one point, and I know of the other ex= periments 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 t= ime. So while there is some simultaneity from the PHY level, there are stil= l two uplink queues feeding into a single downlink queue in the paths betwe= en A and B when there is an AP involved as an intermediary. Thats what I wa= s pointing out as the complex queue-dynamics issue.=0A =0AGlad to hear that= full duplex is being explored for commercial use now. It will certainly do= uble the capacity using the same airtime for twice as much. I won't spend t= ime pointing out that there are even better opportunities that get more tha= n 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).=0A= =0A =0A-----Original Message-----=0AFrom: "Bob McMahon" =0ASent: Sunday, February 10, 2019 9:18pm=0ATo: "David P. Reed" =0ACc: "Jonathan Morton" , "Make-W= ifi-fast" =0ASubject: Re: [Make-wifi-= fast] bloated ath10k=0A=0A=0A=0A=0AJust a reminder with 802.11ax uplink OFD= MA that STA A and B transmits can be "concurrent." Also, there are compa= nies working on full duplex per self cancellation. Kumu networks is one=0A= [ http://kumunetworks.com/ ]( http://kumunetworks.com/ )=0ABob=0A=0A=0AOn M= on, Feb 11, 2019 at 12:30 AM David P. Reed <[ dpreed@deepplum.com ]( mailto= :dpreed@deepplum.com )> wrote:=0ASide note: between two stations talking th= rough 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 f= rom A to B, and both transmissions of a packet from B to A.=0AThat actually= has a significant effect on "queue depth". Please don't call it "interfer= ence", because no packet corruption happens.=0A =0AThis is why merely fixin= g the queueing discipline in the AP alone doesn't necessarily ameliorate bu= fferbloat. The queues in the STA's need to be managed, too.=0A =0AYou guys = know that implicitly, I know I'm not telling you anything you don't know. B= ut 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 t= his in the forwarding paths alone.=0A =0A-----Original Message-----=0AFrom:= "Jonathan Morton" <[ chromatix99@gmail.com ]( mailto:chromatix99@gmail.com= )>=0ASent: Sunday, February 10, 2019 7:38am=0ATo: "Adrian Popescu" <[ adri= annnpopescu@gmail.com ]( mailto:adriannnpopescu@gmail.com )>=0ACc: [ make-w= ifi-fast@lists.bufferbloat.net ]( mailto:make-wifi-fast@lists.bufferbloat.n= et )=0ASubject: Re: [Make-wifi-fast] bloated ath10k=0A=0A=0A=0A> On 10 Feb,= 2019, at 2:24 pm, Adrian Popescu <[ adriannnpopescu@gmail.com ]( mailto:ad= riannnpopescu@gmail.com )> wrote:=0A> =0A> My attempts to use SQM and codel= to reduce wifi bloat didn't seem to get me very far. 802.11ac seems more r= eliable and it seems to be more bloated. ath9k can go as low as 3-5 millise= conds. 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 ex= pect latency to improve with more clients.=0A=0ASome things are unavoidable= when you move to a shared, half-duplex, noisy medium like wifi versus a sw= itched, full-duplex, error-free medium like Ethernet.=0A=0AIf you're gettin= g 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 onl= ine games.=0A=0AAth9k 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 ov= er it when trying to debloat. I think we still have more control over ath10= k than most of the alternatives.=0A=0AIf low latency is mission critical, t= hough - just run a wire.=0A=0A - Jonathan Morton=0A=0A_____________________= __________________________=0AMake-wifi-fast mailing list=0A[ Make-wifi-fast= @lists.bufferbloat.net ]( mailto:Make-wifi-fast@lists.bufferbloat.net )=0A[= https://lists.bufferbloat.net/listinfo/make-wifi-fast ]( https://lists.buf= ferbloat.net/listinfo/make-wifi-fast )_____________________________________= __________=0A Make-wifi-fast mailing list=0A[ Make-wifi-fast@lists.bufferbl= oat.net ]( mailto:Make-wifi-fast@lists.bufferbloat.net )=0A[ https://lists.= bufferbloat.net/listinfo/make-wifi-fast ]( https://lists.bufferbloat.net/li= stinfo/make-wifi-fast ) ------=_20190211094709000000_75528 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Bob - I was focusing o= n the standard Listen-Before-Talk CSMA MAC approach in the current 802.11 t= hrough 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.

=0A

 

=0A

It seems likely to me that by being more oriented around AP-centered s= cheduling it will behave more like a single shared queue without fairness a= t the IP flow level. Since bufferbloat is essentially caused by queuing bel= ow the IP layer without providing timely feedback to the IP endpoints, I do= n't think 802.11ax can fix bufferbloat by itself. Some kind of "queued traf= fic 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 mitigat= e lag under load. And IP flow-level fairness needs to be implementable by t= he IP forwarding layet (ideally collectively among all sharing the up chann= el, which AP scheduling of the uplink can achieve, maybe).

=0A

 

=0A

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 ot= her, the AP-STA links are still a shared queue that can transmit only one p= acket at a time. So while there is some simultaneity from the PHY level, th= ere 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. Tha= ts what I was pointing out as the complex queue-dynamics issue.

=0A

 

=0A

Glad to hear that full du= plex 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 poin= ting 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 al= l theory, not reduced to practice in labs, except a little bit).

=0A

 

=0A

 

=0A

-----Original Message-----
From: "Bob McMahon" <bob.mcmah= on@broadcom.com>
Sent: Sunday, February 10, 2019 9:18pm
To: "D= avid P. Reed" <dpreed@deepplum.com>
Cc: "Jonathan Morton" <ch= romatix99@gmail.com>, "Make-Wifi-fast" <make-wifi-fast@lists.bufferbl= oat.net>
Subject: Re: [Make-wifi-fast] bloated ath10k

=0A

=0A
=0A
Just a reminder with 802.11ax uplink OFDMA that STA A and B transmits ca= n be "concurrent."    Also, there are companies working on full d= uplex per self cancellation.  Kumu networks is one=0A=0A
Bob=0A
=0A
=0A
=0A
=0A
On Mon, Feb 11, 2019 at 12:30 AM David P. Reed <= dpreed@deepplum.com> wrote:=0A
=0A

Side note: between two stations talking through an AP, it's not half dup= lex. It's kind-of quarter-duplex. Each packet between STA A and STA B canno= t  be concurrent with the subsequent packet from A to B, and both tran= smissions of a packet from B to A.

=0A

That actually= has a significant effect on "queue depth".  Please don't call it "int= erference", because no packet corruption happens.

=0A

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.

=0A

&nb= sp;

=0A

You guys know that implicitly, I know I'm no= t telling you anything you don't know. But this queueing needs to be manage= d 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>=0A

 

=0A

-----Original = Message-----
From: "Jonathan Morton" <chromatix99@gmail.com>
Sent: Sund= ay, February 10, 2019 7:38am
To: "Adrian Popescu" <adriannnpopescu@gmail.com>
Cc: make-wifi-fast@lists.bufferbloat.net
Subject: Re: [M= ake-wifi-fast] bloated ath10k

=0A
=0A

> On 10 Feb, 2= 019, at 2:24 pm, Adrian Popescu <adriannnpopescu@gmail.com> wrote:
> =
> My attempts to use SQM and codel to reduce wifi bloat didn't see= m 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 usua= lly test with a single client as I don't expect latency to improve with mor= e 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 bet= ter, 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 co= pe; 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 try= ing 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-wi= fi-fast@lists.bufferbloat.net
https://lists.bufferbloat.n= et/listinfo/make-wifi-fast

=0A
=0A_____________________________= __________________
Make-wifi-fast mailing list
Make-wifi-fast@lis= ts.bufferbloat.net
https://lists.buffe= rbloat.net/listinfo/make-wifi-fast
=0A
=0A
------=_20190211094709000000_75528--