From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (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 4E41D3B2A3 for ; Mon, 27 Mar 2017 09:41:56 -0400 (EDT) Received: by mail-lf0-x234.google.com with SMTP id h125so21512006lfe.0 for ; Mon, 27 Mar 2017 06:41:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=l5M6qKEqfGiF4moVCgh931KO4zCYghtyh1ELPPOLwyE=; b=ixPo9COI7L1zQPTwmbWO5XiFMIZpzoYRMULXlLoNsjALxEa4ov1rI8CC/cVPnwS209 I0ZNFhFQlEaO2QeH4kvW+hcOPMFwq+yhATXHXP8GGyi89kEbXi8GTFHlyUJDV7Fh1jf2 YqyXgbTC+gSp9ofHrCaR2xI5EM0ChXs8Ec6pwQu4sYMv1gjwmI42Yune5weJ/IlaG1BE /O9K3wH6DbixP9TZVP3fv33Ejp0o90rj2dvSk2xXQCkpDJy8HiubV5vJ0mvdWzkZ/WNH qvdFpHlIw0Jk3nRdQOebsDt5UfDt3gQf8PyxNWcM/O/v+7Zqdq9MWIqwOQ9vIH9Hu1Ai fpXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=l5M6qKEqfGiF4moVCgh931KO4zCYghtyh1ELPPOLwyE=; b=HDyXF+LMhNReQDRVG+XOY3ndLFu3USfzrGwyRoPqoaDPnEfybDHkiTAOPglUz31Wcd y957MYiWc46OjKIjVwzfyBmXw0V8Wn4kqiogtDV7ifWtWonvhv8iQqiUd6w9wnnE/ESS RTAJxO/ZisVV2GGjYYD7uqSX3zE8rE9PMtzZlV3KW8ZS2zLBtBWepPPPf0EPaspGzZh0 ObRj8+77qlclK93T4TS48oSQfYBjlS4IVvv+s91s1SKF6Gzm2k9Y414c5RdK5b0RYz9z Xldo80w9vEVCdHXQfQ+mZJBL53ivV2I4n57rq2MHoSokwrNtsmAg0V1VV9HvJRB6Fht+ S62A== X-Gm-Message-State: AFeK/H3f7OM2IuisiAviIW/0Inz246UENxpkApP9Gu2x3+ISOsndbp2sw+YqCBfpBdra5ey2fGgQnkw08xb4wg== X-Received: by 10.28.21.210 with SMTP id 201mr9941056wmv.94.1490622115000; Mon, 27 Mar 2017 06:41:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.139.1 with HTTP; Mon, 27 Mar 2017 06:41:54 -0700 (PDT) Received: by 10.80.139.1 with HTTP; Mon, 27 Mar 2017 06:41:54 -0700 (PDT) In-Reply-To: References: <878tnraqn7.fsf@alrua-x1> From: Jaap Buurman Date: Mon, 27 Mar 2017 15:41:54 +0200 Message-ID: To: Jonathan Morton Cc: make-wifi-fast@lists.bufferbloat.net, =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= Content-Type: multipart/alternative; boundary=001a1145bd74a8b842054bb68163 Subject: Re: [Make-wifi-fast] Major Bufferbloat 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, 27 Mar 2017 13:41:56 -0000 --001a1145bd74a8b842054bb68163 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you very much for your explanation. The test with the earlier mentioned Archer C7 V2 was indeed done on an internet connection with far less upload bandwidth. So the bottleneck was probably on the WAN link instead of wifi link, masking the wifi bufferbloat of the client. Unfortunately, I cannot reposition the antenna, since the router and laptop client both have internal antennas. The 2.4ghz wifi performance of the Mediatek platform is pretty poor in itself, but this is probably an inherent property of the Mediatek platform unfortunately. 2.4ghz performance was definitely way better on the Ath9k platform. On Mar 27, 2017 14:21, "Jonathan Morton" wrote: > > > On 27 Mar, 2017, at 14:56, Jaap Buurman wrote: > > > > Thank you very much for the quick replies! I tried two clients, one > laptop with the Intel 7265ac chipset (Just to be clear, these tests were > done on 2.4ghz n). And another client with an Artheros chipset. I am not > entirely sure which one exactly, I can check in a few hours once I get > home. Both clients were showing the same behavior. The Intel chipset was > using Windows 8.1, while the Artheros chipset was using Windows 10. As a > sidenote, I will try out Ubuntu clients as well once I get home. > > > > I initially also suspected bloated clients. But both clients showed an = A > bufferbloat score on an Archer C7 V2 2.4ghz wifi. This was the exact same > test as the one in the OP, so with 32 upload streams. Unfortunately, I do > not have the Archer anymore, so I cannot repeat the iperf tests. > > Both are reasonably powerful routers with good CPUs and decent wifi > capabilities. However, I now notice this from the thread you linked: > > > As you can see, bufferbloat is fine wired (I am not using SQM, since > that crashes my router, even with fq_codel, it's an outstanding issue wit= h > Mediatek socs). And WAN speeds are more than enough for my wifi connectio= n. > > It=E2=80=99s pretty hard to avoid bufferbloat if you don=E2=80=99t have a= ny bufferbloat > mitigation in place. In the download direction you benefit from the > router's mt76 chipset=E2=80=99s support for wifi-stack AQM/fairness (aka = the result > of the make-wifi-fast project). In the upload direction you have to rely > on whatever Windows does, which (as with many things) is grossly inferior= . > > Under Linux with a recent enough kernel, the ath9k driver also has the > make-wifi-fast code fully enabled. One of your wireless clients might > therefore benefit from that. Alas, the Intel chipsets have a different > architecture which makes a full implementation much more difficult. > > It=E2=80=99s important to realise that bufferbloat always occurs at the e= ntry end > of the bottleneck link. Differences in link bandwidth (which are very > common with wifi, even with the same hardware, if you simply move around = a > bit) can easily move that bottleneck from one link to another. It=E2=80= =99s > therefore important to have AQM installed on every link that you can, in > both directions. > > You may want to double-check that your antennas are properly installed an= d > oriented for best performance. That will tend to improve your wifi link > bandwidth, and might shift the bottleneck back to your uplink, which > appears to be less bloated in the first place. > > - Jonathan Morton > > --001a1145bd74a8b842054bb68163 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you very much for your explanation. The test with t= he earlier mentioned Archer C7 V2 was indeed done on an internet connection= with far less upload bandwidth. So the bottleneck was probably on the WAN = link instead of wifi link, masking the wifi bufferbloat of the client.

Unfortunately, I cannot reposition= the antenna, since the router and laptop client both have internal antenna= s. The 2.4ghz wifi performance of the Mediatek platform is pretty poor in i= tself, but this is probably an inherent property of the Mediatek platform u= nfortunately. 2.4ghz performance was definitely way better on the Ath9k pla= tform.

On Mar 27, 2017 14:21, "Jonathan Morton" <chromatix99@gmail.com> wrote:

> On 27 Mar, 2017, at 14:56, Jaap Buurman <jaapbuurman@gmail.com> wrote:
>
> Thank you very much for the quick replies! I tried two clients, one la= ptop with the Intel 7265ac chipset (Just to be clear, these tests were done= on 2.4ghz n). And another client with an Artheros chipset. I am not entire= ly sure which one exactly, I can check in a few hours once I get home. Both= clients were showing the same behavior. The Intel chipset was using Window= s 8.1, while the Artheros chipset was using Windows 10. As a sidenote, I wi= ll try out Ubuntu clients as well once I get home.
>
> I initially also suspected bloated clients. But both clients showed an= A bufferbloat score on an Archer C7 V2 2.4ghz wifi. This was the exact sam= e test as the one in the OP, so with 32 upload streams. Unfortunately, I do= not have the Archer anymore, so I cannot repeat the iperf tests.

Both are reasonably powerful routers with good CPUs and decent wifi capabil= ities. However, I now notice this from the thread you linked:

> As you can see, bufferbloat is fine wired (I am not using SQM, since t= hat crashes my router, even with fq_codel, it's an outstanding issue wi= th Mediatek socs). And WAN speeds are more than enough for my wifi connecti= on.

It=E2=80=99s pretty hard to avoid bufferbloat if you don=E2=80=99t have any= bufferbloat mitigation in place.=C2=A0 In the download direction you benef= it from the router's mt76 chipset=E2=80=99s support for wifi-stack AQM/= fairness (aka the result of the make-wifi-fast project).=C2=A0 In the uploa= d direction you have to rely on whatever Windows does, which (as with many = things) is grossly inferior.

Under Linux with a recent enough kernel, the ath9k driver also has the make= -wifi-fast code fully enabled.=C2=A0 One of your wireless clients might the= refore benefit from that.=C2=A0 Alas, the Intel chipsets have a different a= rchitecture which makes a full implementation much more difficult.

It=E2=80=99s important to realise that bufferbloat always occurs at the ent= ry end of the bottleneck link.=C2=A0 Differences in link bandwidth (which a= re very common with wifi, even with the same hardware, if you simply move a= round a bit) can easily move that bottleneck from one link to another.=C2= =A0 It=E2=80=99s therefore important to have AQM installed on every link th= at you can, in both directions.

You may want to double-check that your antennas are properly installed and = oriented for best performance.=C2=A0 That will tend to improve your wifi li= nk bandwidth, and might shift the bottleneck back to your uplink, which app= ears to be less bloated in the first place.

=C2=A0- Jonathan Morton

--001a1145bd74a8b842054bb68163--