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

["Toke Høiland-Jørgensen" <toke@redhat.com>]

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 :/

-Toke