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

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

[Sebastian Moeller]

[-- Attachment #1: Type: text/plain, Size: 1959 bytes --]

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.

Best Regards
	Sebastian


> 
> My test setup is a NETGEAR R7800 running OpenWrt with fq_codel'd WiFi and a laptop with an Intel 7260 ac wireless card. The laptop reports an average signal strength of about -77 dBm, while the router has a much harder time hearing the laptop at -98 dBm signal strength with a noise floor of -109 dBm.
> 
> I suspect this extra latency is due to buffering because the laptop has to retransmit a lot of frames due to how poorly the router hears it. Is this correct?
> 
> The associated flent files are attached.
> 
> Michael

[-- Attachment #2: tcp_8up-2020-06-16T115109.277373.room_77dbm.flent.gz --]
[-- Type: application/gzip, Size: 0 bytes --]

[-- Attachment #3: tcp_8down-2020-06-16T114107.429346.room_77dbm.flent.gz --]
[-- Type: application/gzip, Size: 0 bytes --]

[-- Attachment #4: Type: text/plain, Size: 187 bytes --]

>
>
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast

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

[Toke Høiland-Jørgensen]

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

$ 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

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

[Sebastian Moeller]

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

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

[Toke Høiland-Jørgensen]

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

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

[Michael Yartys]

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

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

[Toke Høiland-Jørgensen]

Michael Yartys <michael.yartys@protonmail.com> writes:

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

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

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

[Michael Yartys]

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

> Michael Yartys michael.yartys@protonmail.com writes:
>
> > ‐‐‐‐‐‐‐ 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.
>
> 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...

It seems like I also have TXQs:

$ iw phy | grep TXQ
* [ TXQS ]: FQ-CoDel-enabled intermediate TXQs

I guess that it's probably in the firmware then. IIRC I don't see this behaviour when I have a good connection, but I'll have to perform a test to be sure.

>
> -Toke

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

[Toke Høiland-Jørgensen]

>> > 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...
>
> It seems like I also have TXQs:
>
> $ iw phy | grep TXQ
> * [ TXQS ]: FQ-CoDel-enabled intermediate TXQs
>
> I guess that it's probably in the firmware then. IIRC I don't see this
> behaviour when I have a good connection, but I'll have to perform a
> test to be sure.

Well, it may be that the firmware is doing a lot of retransmits and not
telling the OS. Or it may simply be that the poor connection ends up
dropping the effective rate so the buffering becomes more noticeable.

-Toke

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

[Michael Yartys]

[-- Attachment #1: Type: text/plain, Size: 468 bytes --]

I performed a test under good signal conditions, and the average latency isn't as bad as in the during the test with poor signal conditions. However, there seems to be a lot of jitter that can negatively affect latency sensitive applications. The flent data is attached.

I wonder if this is something that can be reported as a bug. The 7260 is listed as discontinued on Intel's product page, but does that mean that the firmware won't get any bugfixes?


Michael

[-- Attachment #2: tcp_8up-2020-06-30T181004.193102.buffer_test.flent.gz --]
[-- Type: application/gzip, Size: 224256 bytes --]

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

[Toke Høiland-Jørgensen]

Michael Yartys <michael.yartys@protonmail.com> writes:

> I performed a test under good signal conditions, and the average
> latency isn't as bad as in the during the test with poor signal
> conditions. However, there seems to be a lot of jitter that can
> negatively affect latency sensitive applications. The flent data is
> attached.

Yeah, that does seem less horrible.

> I wonder if this is something that can be reported as a bug. The 7260
> is listed as discontinued on Intel's product page, but does that mean
> that the firmware won't get any bugfixes?

No idea... But I wouldn't be surprised if that is indeed what it means :/

-Toke