From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch [185.70.40.136]) (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 EBA4C3B2A4 for ; Tue, 16 Jun 2020 09:00:02 -0400 (EDT) Date: Tue, 16 Jun 2020 12:59:52 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1592312401; bh=5/Y27NnO16yOyjbxm58BahKqNloQ9jCAHHMkEtqUf6M=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=B/luDf1ySBbgk8/9ftUMy4DRCFQ3pnwZ8X24+Yq3gCk7lKJZDwEI7yT219l2KLgOL +vN7fpRSkYSXt1Ucys8d4d/2aeoFVc2JqiqfgZP0G+XdUO1IsfFzd7w60TDbIr21ml 1IXAVrIfrARUUXwOuNdbGURL7Zdd7emN6eiJQ/g8= To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= From: Michael Yartys Cc: Sebastian Moeller , Michael Yartys via Make-wifi-fast Reply-To: Michael Yartys Subject: Re: [Make-wifi-fast] Higher latency on upload under poor signal conditions Message-ID: In-Reply-To: <87lfknz080.fsf@toke.dk> References: <87sgevz1iu.fsf@toke.dk> <709555FC-4203-486B-8B40-86FAD9F0294C@gmx.de> <87lfknz080.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mail.protonmail.ch X-List-Received-Date: Tue, 16 Jun 2020 13:00:03 -0000 Sent with ProtonMail Secure Email. =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Tuesday, 16 June 2020 14:03, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > Sebastian Moeller moeller0@gmx.de writes: > > > Hi Toke, > > > > > On Jun 16, 2020, at 13:35, Toke H=C3=B8iland-J=C3=B8rgensen toke@redh= at.com wrote: > > > Sebastian Moeller moeller0@gmx.de writes: > > > > > > > Hi Michael, > > > > > > > > > On Jun 16, 2020, at 12:18, Michael Yartys via Make-wifi-fast make= -wifi-fast@lists.bufferbloat.net wrote: > > > > > From: Michael Yartys michael.yartys@protonmail.com > > > > > Subject: Higher latency on upload under poor signal conditions > > > > > Date: June 16, 2020 at 12:18:38 GMT+2 > > > > > To: "make-wifi-fast@lists.bufferbloat.net" make-wifi-fast@lists.b= ufferbloat.net > > > > > Reply-To: Michael Yartys michael.yartys@protonmail.com > > > > > Hi > > > > > I decided to run some 8-stream TCP tests at the edge of the range= of my WiFi network, and I noticed that I get higher latency when I run an = upload compared to a download. The latency when downloading is pretty stead= y at right above 30 ms, and when I run the upload it hovers around 80-100 m= s. I think I know why this happens, but I would like to read the opinion of= the mailing list. > > > > > > > > My naive guess would be that air-time fairness by the AP only direc= tly affects the AP's own transmissions, the stations will in all likelihood= not have an fq_codel instance in its wifi-stack (I could be wrong, but I d= o not believe that the 7260ac intel card actually uses airtime fairness yet= /at all). So the 80-100ms might just come from the default wifi parameters = which typically are adjusted for peak thoughput instead of a balanced throu= ghput latency under load set-point. Then again that is my guess, so Kruger-= Dunning might apply. > > > > > > 'iw' will tell you: > > > $ iw phy | grep TXQ > > > * [ TXQS ]: FQ-CoDel-enabled intermediate TXQs > > > > Sweet! Thanks, as I hedged above, it seems like I am/was in Kruger-Dunn= ing territory ;) > > > > > $ lspci | grep Wireless > > > 02:00.0 Network controller: Intel Corporation Wireless 8265 / 8275 (r= ev 78) > > > Other than that, the 'lots of retries' theory does sound plausible. O= r > > > it could be buffering in the firmware. Or a combination of all of tha= t :) > > > > Out of curiosity, how would one see the retries? > > Some hardware has counters, but not sure if the Intel devices expose > anything. Otherwise, you'll need to sniff the air I'm afraid :/ Is this what I would be looking for (I only included the relevant part of t= he output)? $ iw wlp18s0 station dump tx packets:=09742091 tx retries:=09417 This is the output after running an upload test and getting pretty much the= same results. I disabled and re-enabled the wireless NIC before the test s= ince that seems to reset the stats. It doesn't really look like the retry r= ate is high, but I don't really know what's considered high in the first pl= ace. > > -Toke