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

[Sebastian Moeller <moeller0@gmx.de>]

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?

Thanks
	Sebastian

> 
> -Toke