From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id EDE0F3CB38 for ; Sun, 10 Feb 2019 21:18:28 -0500 (EST) Received: by mail-ed1-x52e.google.com with SMTP id 10so1327811eds.7 for ; Sun, 10 Feb 2019 18:18:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=S/Zape/5Ij178kRUwO5LJMRfAXblYBEfwbsiIPC3KTQ=; b=IWuXFy5jGOBKER3jk9BkuCSBvs7mYIzq4GjYXupWDWRl0UnoGy7Zd0trbDfNrUJY8h rYKmn10/KTNvTdkLZW35g50cUf5GAHq+c07bd8MSM/PbpidAzdrDdO7hC5lcxPy8GWcR BjSeg9MiSheqf4ki/Kq3ULa3ThKZrcfjOuApE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=S/Zape/5Ij178kRUwO5LJMRfAXblYBEfwbsiIPC3KTQ=; b=EfmevXLrX2axDS4aKD45wH9K5vbTIH0bXH4iIc14syKv6RCogFumjAyBs2Yl2EuLQI GrB4q1mSc6jz0KpiLDefpvRNQFu4ckr+jCQuWQjkTydCXe67GyIYa3gioefG+hLIbk0b rQMVz5vAGlDTdPwieLL612rVzycw4dMUgLETbQt1zd8GBiZNIoYu9JhWvYmne4GnY0J3 zZ5rrLlWe4cPM+KsxqoEt3rh7bpDLFkgLATyb+/33P6v3aV+xsU/6/Hpp0FTYlJf9s9s MaSHkeJwsTJDnDWzyNWj1IXHuifmhfRy40MMAKDJc5JMHPnOSERTVEE9lKmaC0nUcgJY 5WvQ== X-Gm-Message-State: AHQUAuYeS8zwB6XA/YKqTkJ9gbh5xxOX7A5X7/WR0V3DVi8jAAiLj2qg e1lK00X7qBySxacKpymNbSZ5T55U+G4Ck5uv3PhChg== X-Google-Smtp-Source: AHgI3IaMqaCB2gzPg5Xofgj3YPEtia3l2i7pkRVt9KCJkzlWyUAU0Pfy5pSOxMOfd7mbMGDWy8LqLja9bBxB9+PPhX8= X-Received: by 2002:a50:bb68:: with SMTP id y95mr10922060ede.177.1549851507873; Sun, 10 Feb 2019 18:18:27 -0800 (PST) MIME-Version: 1.0 References: <3CB198EB-2844-42DB-9E5A-26708BFD7304@gmail.com> <1549825225.478726910@apps.rackspace.com> In-Reply-To: <1549825225.478726910@apps.rackspace.com> From: Bob McMahon Date: Mon, 11 Feb 2019 07:48:16 +0530 Message-ID: To: "David P. Reed" Cc: Jonathan Morton , Make-Wifi-fast Content-Type: multipart/alternative; boundary="000000000000952449058194ec3b" 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 02:18:29 -0000 --000000000000952449058194ec3b Content-Type: text/plain; charset="UTF-8" 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 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" > Sent: Sunday, February 10, 2019 7:38am > To: "Adrian Popescu" > Cc: make-wifi-fast@lists.bufferbloat.net > Subject: Re: [Make-wifi-fast] bloated ath10k > > > On 10 Feb, 2019, at 2:24 pm, Adrian Popescu > 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 --000000000000952449058194ec3b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just a reminder with 802.11ax uplink OFDM= A that STA A and B transmits can be "concurrent."=C2=A0 =C2=A0 Al= so, there are companies working on full duplex per self cancellation.=C2=A0= Kumu networks is one


Bob

On = Mon, Feb 11, 2019 at 12:30 AM David P. Reed <dpreed@deepplum.com> wrote:

Side note: bet= ween 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=C2=A0 b= e concurrent with the subsequent packet from A to B, and both transmissions= of a packet from B to A.

That a= ctually has a significant effect on "queue depth".=C2=A0 Please d= on't call it "interference", because no packet corruption hap= pens.

=C2=A0=

This i= s why merely fixing the queueing discipline in the AP alone doesn't nec= essarily ameliorate bufferbloat. The queues in the STA's need to be man= aged, too.

=C2=A0=

You gu= ys know that implicitly, I know I'm not telling you anything you don= 9;t know. But this queueing needs to be managed in such a way that the back= off in TCP is signaled. That is, packets need to be dropped or marked. You = can't fix this in the forwarding paths alone.

=C2=A0=

-----O= riginal Message-----
From: "Jonathan Morton" <chromatix99@gmail.com>=
Sent: Sunday, February 10, 2019 7:38am
To: "Adrian Popescu"= ; <adrian= nnpopescu@gmail.com>
Cc: make-wifi-fast@lists.bufferbloat.net<= br>Subject: Re: [Make-wifi-fast] bloated ath10k

> O= n 10 Feb, 2019, at 2:24 pm, Adrian Popescu <adriannnpopescu@gmail.com> wrote:=
>
> My attempts to use SQM and codel to reduce wifi bloat did= n'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 usua= lly in the 20-50 milliseconds range (or more, based on the number of statio= ns). I usually test with a single client as I don't expect latency to i= mprove with more clients.

Some things are unavoidable when you move = to a shared, half-duplex, noisy medium like wifi versus a switched, full-du= plex, 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 w= ish for better, but not long ago you could be looking at multiple seconds i= n bad cases. At the levels you're now seeing, ordinary interactive prot= ocols like DNS and HTTP will work reliably and quickly, and even VoIP shoul= d be able to cope; you'll likely only really notice a problem with onli= ne games.

Ath9k has some advantages over ath10k in this area. Its MA= C is managed at a lower level by the driver, so we have much more control o= ver it when trying to debloat. I think we still have more control over ath1= 0k than most of the alternatives.

If low latency is mission critical= , though - just run a wire.

- Jonathan Morton

______________= _________________________________
Make-wifi-fast mailing list
Make-wif= i-fast@lists.bufferbloat.net
https://lists.bufferbloat.net/= listinfo/make-wifi-fast

_______________________________________________
Make-wifi-fast mailing list
M= ake-wifi-fast@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/make-wif= i-fast
--000000000000952449058194ec3b--