[Make-wifi-fast] Major Bufferbloat

[Make-wifi-fast] Major Bufferbloat

[Jaap Buurman]

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

Hello all,

I'm seeing major bufferbloat issues on my 2.4ghz network that is run on a
DIR-860l B1, which uses the MT7602E chip. I am running the latest stable
LEDE. Strangely, I am only getting bufferbloat issues with a high number of
concurrent data streams from my wireless-n client to my router. An
extensive test showing the exact situation in which my bufferbloat issues
are occuring are found in the 7th post of the following thread:

https://forum.lede-project.org/t/dir-860l-rev-b1-very-poor-wifi-performance/2612/8

I was hoping some of the bufferbloat gurus here would know what is going
on, and hopefully how to fix this issue. Thank you very much in advance.

Yours sincerely,

Jaap Buurman

[-- Attachment #2: Type: text/html, Size: 1061 bytes --]

Re: [Make-wifi-fast] Major Bufferbloat

[Jonathan Morton]

> On 27 Mar, 2017, at 14:41, Jaap Buurman <jaapbuurman@gmail.com> wrote:
> 
> a high number of concurrent data streams from my wireless-n client to my router

In that case, the bufferbloat is probably in your client, rather than in the router.  Details of that device may aid diagnosis.

 - Jonathan Morton

Re: [Make-wifi-fast] Major Bufferbloat

[Toke Høiland-Jørgensen]

Jaap Buurman <jaapbuurman@gmail.com> writes:

> Hello all,
>
> I'm seeing major bufferbloat issues on my 2.4ghz network that is run
> on a DIR-860l B1, which uses the MT7602E chip. I am running the latest
> stable LEDE. Strangely, I am only getting bufferbloat issues with a
> high number of concurrent data streams from my wireless-n client to my
> router. An extensive test showing the exact situation in which my
> bufferbloat issues are occuring are found in the 7th post of the
> following thread:

What chipset/driver is the client running? Sounds like that is bloated?

-Toke

Re: [Make-wifi-fast] Major Bufferbloat

[Jaap Buurman]

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

Thank you very much for the quick replies! I tried two clients, one laptop
with the Intel 7265ac chipset (Just to be clear, these tests were done on
2.4ghz n). And another client with an Artheros chipset. I am not entirely
sure which one exactly, I can check in a few hours once I get home. Both
clients were showing the same behavior. The Intel chipset was using Windows
8.1, while the Artheros chipset was using Windows 10. As a sidenote, I will
try out Ubuntu clients as well once I get home.

I initially also suspected bloated clients. But both clients showed an A
bufferbloat score on an Archer C7 V2 2.4ghz wifi. This was the exact same
test as the one in the OP, so with 32 upload streams. Unfortunately, I do
not have the Archer anymore, so I cannot repeat the iperf tests.

On Mar 27, 2017 13:46, "Toke Høiland-Jørgensen" <toke@toke.dk> wrote:

> Jaap Buurman <jaapbuurman@gmail.com> writes:
>
> > Hello all,
> >
> > I'm seeing major bufferbloat issues on my 2.4ghz network that is run
> > on a DIR-860l B1, which uses the MT7602E chip. I am running the latest
> > stable LEDE. Strangely, I am only getting bufferbloat issues with a
> > high number of concurrent data streams from my wireless-n client to my
> > router. An extensive test showing the exact situation in which my
> > bufferbloat issues are occuring are found in the 7th post of the
> > following thread:
>
> What chipset/driver is the client running? Sounds like that is bloated?
>
> -Toke
>

[-- Attachment #2: Type: text/html, Size: 1915 bytes --]

Re: [Make-wifi-fast] Major Bufferbloat

[Jonathan Morton]

> On 27 Mar, 2017, at 14:56, Jaap Buurman <jaapbuurman@gmail.com> wrote:
> 
> Thank you very much for the quick replies! I tried two clients, one laptop with the Intel 7265ac chipset (Just to be clear, these tests were done on 2.4ghz n). And another client with an Artheros chipset. I am not entirely sure which one exactly, I can check in a few hours once I get home. Both clients were showing the same behavior. The Intel chipset was using Windows 8.1, while the Artheros chipset was using Windows 10. As a sidenote, I will try out Ubuntu clients as well once I get home.
> 
> I initially also suspected bloated clients. But both clients showed an A bufferbloat score on an Archer C7 V2 2.4ghz wifi. This was the exact same test as the one in the OP, so with 32 upload streams. Unfortunately, I do not have the Archer anymore, so I cannot repeat the iperf tests.

Both are reasonably powerful routers with good CPUs and decent wifi capabilities. However, I now notice this from the thread you linked:

> As you can see, bufferbloat is fine wired (I am not using SQM, since that crashes my router, even with fq_codel, it's an outstanding issue with Mediatek socs). And WAN speeds are more than enough for my wifi connection.

It’s pretty hard to avoid bufferbloat if you don’t have any bufferbloat mitigation in place.  In the download direction you benefit from the router's mt76 chipset’s support for wifi-stack AQM/fairness (aka the result of the make-wifi-fast project).  In the upload direction you have to rely on whatever Windows does, which (as with many things) is grossly inferior.

Under Linux with a recent enough kernel, the ath9k driver also has the make-wifi-fast code fully enabled.  One of your wireless clients might therefore benefit from that.  Alas, the Intel chipsets have a different architecture which makes a full implementation much more difficult.

It’s important to realise that bufferbloat always occurs at the entry end of the bottleneck link.  Differences in link bandwidth (which are very common with wifi, even with the same hardware, if you simply move around a bit) can easily move that bottleneck from one link to another.  It’s therefore important to have AQM installed on every link that you can, in both directions.

You may want to double-check that your antennas are properly installed and oriented for best performance.  That will tend to improve your wifi link bandwidth, and might shift the bottleneck back to your uplink, which appears to be less bloated in the first place.

 - Jonathan Morton

Re: [Make-wifi-fast] Major Bufferbloat

[Jaap Buurman]

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

Thank you very much for your explanation. The test with the earlier
mentioned Archer C7 V2 was indeed done on an internet connection with far
less upload bandwidth. So the bottleneck was probably on the WAN link
instead of wifi link, masking the wifi bufferbloat of the client.

Unfortunately, I cannot reposition the antenna, since the router and laptop
client both have internal antennas. The 2.4ghz wifi performance of the
Mediatek platform is pretty poor in itself, but this is probably an
inherent property of the Mediatek platform unfortunately. 2.4ghz
performance was definitely way better on the Ath9k platform.

On Mar 27, 2017 14:21, "Jonathan Morton" <chromatix99@gmail.com> wrote:

>
> > On 27 Mar, 2017, at 14:56, Jaap Buurman <jaapbuurman@gmail.com> wrote:
> >
> > Thank you very much for the quick replies! I tried two clients, one
> laptop with the Intel 7265ac chipset (Just to be clear, these tests were
> done on 2.4ghz n). And another client with an Artheros chipset. I am not
> entirely sure which one exactly, I can check in a few hours once I get
> home. Both clients were showing the same behavior. The Intel chipset was
> using Windows 8.1, while the Artheros chipset was using Windows 10. As a
> sidenote, I will try out Ubuntu clients as well once I get home.
> >
> > I initially also suspected bloated clients. But both clients showed an A
> bufferbloat score on an Archer C7 V2 2.4ghz wifi. This was the exact same
> test as the one in the OP, so with 32 upload streams. Unfortunately, I do
> not have the Archer anymore, so I cannot repeat the iperf tests.
>
> Both are reasonably powerful routers with good CPUs and decent wifi
> capabilities. However, I now notice this from the thread you linked:
>
> > As you can see, bufferbloat is fine wired (I am not using SQM, since
> that crashes my router, even with fq_codel, it's an outstanding issue with
> Mediatek socs). And WAN speeds are more than enough for my wifi connection.
>
> It’s pretty hard to avoid bufferbloat if you don’t have any bufferbloat
> mitigation in place.  In the download direction you benefit from the
> router's mt76 chipset’s support for wifi-stack AQM/fairness (aka the result
> of the make-wifi-fast project).  In the upload direction you have to rely
> on whatever Windows does, which (as with many things) is grossly inferior.
>
> Under Linux with a recent enough kernel, the ath9k driver also has the
> make-wifi-fast code fully enabled.  One of your wireless clients might
> therefore benefit from that.  Alas, the Intel chipsets have a different
> architecture which makes a full implementation much more difficult.
>
> It’s important to realise that bufferbloat always occurs at the entry end
> of the bottleneck link.  Differences in link bandwidth (which are very
> common with wifi, even with the same hardware, if you simply move around a
> bit) can easily move that bottleneck from one link to another.  It’s
> therefore important to have AQM installed on every link that you can, in
> both directions.
>
> You may want to double-check that your antennas are properly installed and
> oriented for best performance.  That will tend to improve your wifi link
> bandwidth, and might shift the bottleneck back to your uplink, which
> appears to be less bloated in the first place.
>
>  - Jonathan Morton
>
>

[-- Attachment #2: Type: text/html, Size: 3762 bytes --]

Re: [Make-wifi-fast] Major Bufferbloat

[marty]

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



On 03/27/2017 09:41 AM, Jaap Buurman wrote:
> Thank you very much for your explanation. The test with the earlier 
> mentioned Archer C7 V2 was indeed done on an internet connection with 
> far less upload bandwidth. So the bottleneck was probably on the WAN 
> link instead of wifi link, masking the wifi bufferbloat of the client.
>
> Unfortunately, I cannot reposition the antenna, since the router and 
> laptop client both have internal antennas. The 2.4ghz wifi performance 
> of the Mediatek platform is pretty poor in itself, but this is 
> probably an inherent property of the Mediatek platform unfortunately. 
> 2.4ghz performance was definitely way better on the Ath9k platform.
>
In case it is helpful, related braindump follows, maybe it will be helpful:
When I worked deploying outdoor nodes in campgrounds and such we moved 
from using long coax antenna cables to putting the AP and clients with 
external ants mounted up on the poles with a single POE cable for data 
and power (for non WAN repeaters, just power).  The run from the router 
to the ant was just a  ~6" pigtail and gave us several dB advantage of 
the long coax.  With an RF transparent enclosure (I suppose you could 
get away with tupperware + rtv at the low end; with more frequent 
inspections) you could put any router up high/outside similarly. Put 
tiny weep holes (too small for nest building flying insects) in the 
lower corners to drain any condensate and paint the enclosure with a 
non-metallic base bright white to reflect UV and heat better if it will 
be in direct sunlight.  Non-metallic box and paint because your antennas 
are in there and need to "see". We used metal boxes with external 
antenna connections so I'm winging it on the tupperware/paint thing but 
most plastics are mostly transparent at 2.4Ghz+.  If you go too high in 
populated areas you pick up a lot of noise from the surrounding area APs 
and clients on same or near channels and other RF noise sources in the 
band.  Go up just high enough to maximize LOS and minimize longer 
distance noise from other APs. If you can mount under an eave out of 
direct sunlight then probably better for both UV issues and heat issues 
for the router.  For ventilation, if required (lm-sensors package is 
your friend for determining this; or just climb up and check how it 
feels on hot days), use normal downward facing vent type slits along the 
top edge of vertical face (to keep rain out) and put window screen 
behind slits to prevent insect nesting.

[-- Attachment #2: Type: text/html, Size: 3204 bytes --]

Re: [Make-wifi-fast] Major Bufferbloat

[marty]

On 03/27/2017 10:25 AM, marty wrote:

> For ventilation, if required (lm-sensors package is your friend for 
> determining this; or just climb up and check how it feels on hot 
> days), use normal downward facing vent type slits along the top edge 
> of vertical face (to keep rain out) and put window screen behind slits 
> to prevent insect nesting.

addendum:
If you end up needing vents at the top, the just drill a bunch more weep 
holes in the bottom to allow air to rise through the interior and out 
the vents.

Also, you don't necessarily need vents, especially not for simple short 
term testing of an enclosure or mount location. But once you find the 
sweet spot, you definitely want weep holes for condensation and if hit 
by the sun and/or working hard at all that router is going to want a bit 
of airflow.  For short testing of your setup no reason to go crazy on it.

No holes on the top surface. I'm imagining the box mounted vertically 
for airflow and moisture weeping reasons, and most routers are designed 
to stand up on edge these days.

I don't know if antenna polarity becomes an issue or not with internal 
antenna designs mounted 90 off vertically as I haven't worked that way 
with internal antenna routers.

Marty