From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133]) (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 B07B23B2A4 for ; Tue, 16 Jun 2020 09:14:24 -0400 (EDT) Date: Tue, 16 Jun 2020 13:14:21 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1592313263; bh=PLmQwaRiw3v8hFey7ZAHj02YhvK9ICMrSIXBn/7xe0U=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=LNQB3ClMo2TOEGJXVf09SBV9Fdn/QB8YI1vbaUMHDEarg/tolrIzA94WHWAaUsXvX um000If5PRrKno5Wrobc+RfdbLmsWXrqaUEaY8IjSIrrg/nXyGPqiEkbl+VO0TQ7/8 nZR2QCHgDroFwUbueEjDrXiHxaM253uQENvhAdzU= To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= From: Michael Yartys Cc: "make-wifi-fast@lists.bufferbloat.net" Reply-To: Michael Yartys Subject: Re: [Make-wifi-fast] Higher latency on upload under poor signal conditions Message-ID: In-Reply-To: <87a713yxat.fsf@toke.dk> References: <87sgevz1iu.fsf@toke.dk> <709555FC-4203-486B-8B40-86FAD9F0294C@gmx.de> <87lfknz080.fsf@toke.dk> <87a713yxat.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:14:24 -0000 =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 15:06, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > Michael Yartys michael.yartys@protonmail.com writes: > > > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Origina= l Message =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 toke@r= edhat.com wrote: > > > > > Sebastian Moeller moeller0@gmx.de writes: > > > > > > > Hi Toke, > > > > > > > > > On Jun 16, 2020, at 13:35, Toke H=C3=B8iland-J=C3=B8rgensen toke@= redhat.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 condition= s > > > > > > > Date: June 16, 2020 at 12:18:38 GMT+2 > > > > > > > To: "make-wifi-fast@lists.bufferbloat.net" make-wifi-fast@lis= ts.bufferbloat.net > > > > > > > Reply-To: Michael Yartys michael.yartys@protonmail.com > > > > > > > Hi > > > > > > > I decided to run some 8-stream TCP tests at the edge of the r= ange 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 s= teady at right above 30 ms, and when I run the upload it hovers around 80-1= 00 ms. I think I know why this happens, but I would like to read the opinio= n of the mailing list. > > > > > > > > > > > > My naive guess would be that air-time fairness by the AP only d= irectly affects the AP's own transmissions, the stations will in all likeli= hood not have an fq_codel instance in its wifi-stack (I could be wrong, but= I do 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 paramet= ers which typically are adjusted for peak thoughput instead of a balanced t= hroughput latency under load set-point. Then again that is my guess, so Kru= ger-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-= Dunning territory ;) > > > > > > > > > $ lspci | grep Wireless > > > > > 02:00.0 Network controller: Intel Corporation Wireless 8265 / 827= 5 (rev 78) > > > > > Other than that, the 'lots of retries' theory does sound plausibl= e. Or > > > > > it could be buffering in the firmware. Or a combination of all of= that :) > > > > > > > > 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 the output)? > > $ iw wlp18s0 station dump > > tx packets: 742091 > > tx retries: 417 > > 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 since that seems to reset the stats. It doesn't really > > look like the retry rate is high, but I don't really know what's > > considered high in the first place. > > That does not seem overly high, no. I guess 80ms could just be queueing > delay, either in the firmware, or because your driver is not using > TXQs... It seems like I also have TXQs: $ iw phy | grep TXQ * [ TXQS ]: FQ-CoDel-enabled intermediate TXQs I guess that it's probably in the firmware then. IIRC I don't see this beha= viour when I have a good connection, but I'll have to perform a test to be = sure. > > -Toke