From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it1-x12a.google.com (mail-it1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 03B5F3BA8E for ; Sun, 10 Feb 2019 09:37:27 -0500 (EST) Received: by mail-it1-x12a.google.com with SMTP id q78so13464781itc.0 for ; Sun, 10 Feb 2019 06:37:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pMRtMXBBRYqobho6BAaATG3scHs19zYnoS0zFerMBuA=; b=sIYyqS+dWJKcNOMZAwA5wGjn8GsKro3dEKhSyFGjDJMbBqEHRVy+2h4bw0M0IorjAC 6By2bkbwrB6+dkli/6/liAPIcfxGbekQJt4q5mP/6LyxbSoB0tKyTARWQm8ERMyLZ0+p RsFcGj8gQ0RPTuYFg+eOiJubtSPHUoUWpTIBav2L5ek4qBfhn1JWG5fNCFaFuhA/kEs9 AIVwC1n0rsEP2txmK/erbq6M081MirQhXpg29rBAlJOqGoOLTY45AVukGuejgwxV6gBQ 2vIEmFs3Ymn/zEbS4xpA67xQgC6GdAR4eRgzl9EqsuSDpP/HBPSbV+3zDP4j66KyVFVV kskw== 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=pMRtMXBBRYqobho6BAaATG3scHs19zYnoS0zFerMBuA=; b=hh57aKZ2/VV077BlFh+exn5vtV55czhLVUnrk1s/Gulzlh3ZEZXaLKH+v7nzCtdSm0 a+t8YDOT3K3Pqk4QXs2kajyXnVVQOLtWEhFBQdeVZZkSLqHYR9rCPhlk7pa+ltno4+q8 7djyqOavFQyLBfUm4uOb5upJerXYWyCHbMEzmEQBCuQGmg/t5uG2Rtu0gcu9aDw3I9zD QukS6lGaEf7SozUKrardFafqxqrRekdOwPnbCbXjDQal9Qc+3JG5Zx5rG2Zfq6LBbwCb TaW2oddTvItSoIZdlN2uYd+FoUpoVCVmcGHiihCTQ7UzUuEEdnm1wf4GOUxiZRgJmjqZ rrxg== X-Gm-Message-State: AHQUAuY6D1fHbc5pNuYWI9iC0VsXT9q9BVUbXw6IaKEpjc5j2wc6PvPo msY2amnez18bTBGX3mCQy3T/oY3IO/EF+OaNFMs= X-Google-Smtp-Source: AHgI3IY8umLuUcoDchJoPfoZi3+dUMwUj/2HBvMO+jCz73GjAl2nNjn2bwyUKzlUSi47uHv419RPbHCGs6IXIVlWZpg= X-Received: by 2002:a5d:8896:: with SMTP id d22mr2382874ioo.249.1549809447534; Sun, 10 Feb 2019 06:37:27 -0800 (PST) MIME-Version: 1.0 References: <3CB198EB-2844-42DB-9E5A-26708BFD7304@gmail.com> In-Reply-To: <3CB198EB-2844-42DB-9E5A-26708BFD7304@gmail.com> From: Adrian Popescu Date: Sun, 10 Feb 2019 16:37:16 +0200 Message-ID: To: Jonathan Morton Cc: make-wifi-fast@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="0000000000009702dc05818b21f2" 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 14:37:28 -0000 --0000000000009702dc05818b21f2 Content-Type: text/plain; charset="UTF-8" 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 wrote: > > 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 > > --0000000000009702dc05818b21f2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Running a wire isn't an option f= or devices which don't have ethernet ports.

I&= #39;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 caus= e stuttering during a voice or video call are the real problem. The stutter= ing may not have been caused by these spikes.

It s= eems 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 com= pare 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 rel= evant.



On Sun, Feb 10, 2019 at= 2:38 PM Jonathan Morton <chrom= atix99@gmail.com> wrote:
> On 10 Feb, 2019, at 2:24 pm, Adrian Popescu <adriannnpopescu@gm= ail.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 bl= oated. 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 usuall= y test with a single client as I don't expect latency to improve with m= ore clients.

Some things are unavoidable when you move to a shared, half-duplex, noisy m= edium like wifi versus a switched, full-duplex, error-free medium like Ethe= rnet.

If you're getting 20-50ms under load, then I think things are working q= uite well with wifi.=C2=A0 We can wish for better, but not long ago you cou= ld be looking at multiple seconds in bad cases.=C2=A0 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 like= ly only really notice a problem with online games.

Ath9k has some advantages over ath10k in this area.=C2=A0 Its MAC is manage= d at a lower level by the driver, so we have much more control over it when= trying to debloat.=C2=A0 I think we still have more control over ath10k th= an most of the alternatives.

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

=C2=A0- Jonathan Morton

--0000000000009702dc05818b21f2--