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

[Michael Yartys <michael.yartys@protonmail.com>]

Sent with ProtonMail Secure Email.

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

> Sebastian Moeller moeller0@gmx.de writes:
>
> > Hi Toke,
> >
> > > On Jun 16, 2020, at 13:35, Toke Høiland-Jørgensen 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 conditions
> > > > > Date: June 16, 2020 at 12:18:38 GMT+2
> > > > > To: "make-wifi-fast@lists.bufferbloat.net" make-wifi-fast@lists.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 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.

>
> -Toke