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

[Toke Høiland-Jørgensen]

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...

-Toke