From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp118.iad3a.emailsrvr.com (smtp118.iad3a.emailsrvr.com [173.203.187.118]) (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 E03033BA8E for ; Sun, 10 Feb 2019 14:00:25 -0500 (EST) Received: from smtp39.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp39.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id AFECD3E71; Sun, 10 Feb 2019 14:00:25 -0500 (EST) X-SMTPDoctor-Processed: csmtpprox beta Received: from smtp39.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp39.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id AA0C83E97; Sun, 10 Feb 2019 14:00:25 -0500 (EST) Received: from app30.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp39.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 87E083E71; Sun, 10 Feb 2019 14:00:25 -0500 (EST) X-Sender-Id: dpreed@deepplum.com Received: from app30.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Sun, 10 Feb 2019 14:00:25 -0500 Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app30.wa-webapps.iad3a (Postfix) with ESMTP id 757B7E004A; Sun, 10 Feb 2019 14:00:25 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Sun, 10 Feb 2019 14:00:25 -0500 (EST) X-Auth-ID: dpreed@deepplum.com Date: Sun, 10 Feb 2019 14:00:25 -0500 (EST) From: "David P. Reed" To: "Jonathan Morton" Cc: "Adrian Popescu" , make-wifi-fast@lists.bufferbloat.net MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20190210140025000000_69930" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: <3CB198EB-2844-42DB-9E5A-26708BFD7304@gmail.com> References: <3CB198EB-2844-42DB-9E5A-26708BFD7304@gmail.com> Message-ID: <1549825225.478726910@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: Sun, 10 Feb 2019 19:00:26 -0000 ------=_20190210140025000000_69930 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0ASide 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 transmiss= ions of a packet from B to A.=0AThat actually has a significant effect on "= queue depth". Please don't call it "interference", because no packet corru= ption happens.=0A =0AThis is why merely fixing the queueing discipline in t= he AP alone doesn't necessarily ameliorate bufferbloat. The queues in the S= TA's need to be managed, too.=0A =0AYou guys know that implicitly, I know I= 'm not telling you anything you don't know. But this queueing needs to be m= anaged 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 al= one.=0A =0A-----Original Message-----=0AFrom: "Jonathan Morton" =0ASent: Sunday, February 10, 2019 7:38am=0ATo: "Adrian Popescu= " =0ACc: make-wifi-fast@lists.bufferbloat.net=0A= Subject: Re: [Make-wifi-fast] bloated ath10k=0A=0A=0A=0A> On 10 Feb, 2019, = at 2:24 pm, Adrian Popescu wrote:=0A> =0A> My a= ttempts to use SQM and codel to reduce wifi bloat didn't seem to get me ver= y 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 milliseco= nds 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.=0A= =0ASome things are unavoidable when you move to a shared, half-duplex, nois= y medium like wifi versus a switched, full-duplex, error-free medium like E= thernet.=0A=0AIf 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 no= w seeing, ordinary interactive protocols like DNS and HTTP will work reliab= ly and quickly, and even VoIP should be able to cope; you'll likely only re= ally notice a problem with online games.=0A=0AAth9k has some advantages ove= r ath10k in this area. Its MAC is managed at a lower level by the driver, s= o we have much more control over it when trying to debloat. I think we stil= l have more control over ath10k than most of the alternatives.=0A=0AIf low = latency is mission critical, though - just run a wire.=0A=0A - Jonathan Mor= ton=0A=0A_______________________________________________=0AMake-wifi-fast m= ailing list=0AMake-wifi-fast@lists.bufferbloat.net=0Ahttps://lists.bufferbl= oat.net/listinfo/make-wifi-fast ------=_20190210140025000000_69930 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

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 wit= h the subsequent packet from A to B, and both transmissions of a packet fro= m B to A.

=0A

That actually has a significant effect= on "queue depth".  Please don't call it "interference", because no pa= cket corruption happens.

=0A

 

=0A

This is why merely fixing the queueing discipline in the AP al= one doesn't necessarily ameliorate bufferbloat. The queues in the STA's nee= d to be managed, too.

=0A

 

=0A

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 th= e backoff in TCP is signaled. That is, packets need to be dropped or marked= . You can't fix this in the forwarding paths alone.

=0A

 

=0A

-----Original Message-----
From:= "Jonathan Morton" <chromatix99@gmail.com>
Sent: Sunday, Februar= y 10, 2019 7:38am
To: "Adrian Popescu" <adriannnpopescu@gmail.com&g= t;
Cc: make-wifi-fast@lists.bufferbloat.net
Subject: Re: [Make-wi= fi-fast] bloated ath10k

=0A
= =0A

> On 10 Feb, 2019, at 2:24 pm, Adrian Popescu &l= t;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 l= ow 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 cli= ent as I don't expect latency to improve with more clients.

Some= things are unavoidable when you move to a shared, half-duplex, noisy mediu= m 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 reliabl= y and quickly, and even VoIP should be able to cope; you'll likely only rea= lly notice a problem with online games.

Ath9k has some advantage= s over ath10k in this area. Its MAC is managed at a lower level by the driv= er, 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

=0A ------=_20190210140025000000_69930--