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

[Toke Høiland-Jørgensen]

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

$ 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 :)

-Toke