[Make-wifi-fast] Higher latency on upload under poor signal conditions

[Michael Yartys]

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, 16 June 2020 15:06, Toke Høiland-Jørgensen <toke at redhat.com> wrote:

> Michael Yartys michael.yartys at protonmail.com writes:
>
> > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> > On Tuesday, 16 June 2020 14:03, Toke Høiland-Jørgensen toke at redhat.com wrote:
> >
> > > Sebastian Moeller moeller0 at gmx.de writes:
> > >
> > > > Hi Toke,
> > > >
> > > > > On Jun 16, 2020, at 13:35, Toke Høiland-Jørgensen toke at redhat.com wrote:
> > > > > Sebastian Moeller moeller0 at gmx.de writes:
> > > > >
> > > > > > Hi Michael,
> > > > > >
> > > > > > > On Jun 16, 2020, at 12:18, Michael Yartys via Make-wifi-fast make-wifi-fast at lists.bufferbloat.net wrote:
> > > > > > > From: Michael Yartys michael.yartys at 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 at lists.bufferbloat.net" make-wifi-fast at lists.bufferbloat.net
> > > > > > > Reply-To: Michael Yartys michael.yartys at 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 steady at right above 30 ms, and when I run the upload it hovers around 80-100 ms. 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 directly 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 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 parameters which typically are adjusted for peak thoughput instead of a balanced throughput 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-Dunning territory ;)
> > > >
> > > > > $ lspci | grep Wireless
> > > > > 02:00.0 Network controller: Intel Corporation Wireless 8265 / 8275 (rev 78)
> > > > > Other than that, the 'lots of retries' theory does sound plausible. 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 behaviour when I have a good connection, but I'll have to perform a test to be sure.

>
> -Toke