[Make-wifi-fast] Bufferbloat on Norwegian train wifi

[Michael Yartys]

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, 23 June 2020 12:11, Toke Høiland-Jørgensen <toke at redhat.com> wrote:

> Michael Yartys michael.yartys at protonmail.com writes:
>
> > Wow, those are some truly crappy networks!
>
> Yeah, 'bloat-bragging' seems to have become quite the sport on these
> mailing lists ;)
>
> > I'll try to contact Vy to get them to do something about it. I wonder
> > how much of this might be due to the equipment on their trains though.
> > I decided to measure the bufferbloat on the LTE network in my
> > neighbourhood, and on average I got 300 ms above baseline while
> > running an 8-stream TCP download. Then again, I ran this test with my
> > phone acting as a hotspot, and the results might be affected by that.
> > Does anybody know if this methodology produces reliable results? I
> > presume that even the very short peak of 86 Mbps shouldn't really
> > cause much WiFi-related bufferbloat.
>
> Hard to say from first principles. 300ms doesn't sound unrealistic for
> bloat on an LTE network and if you have a good WiFi connection on your
> phone the WiFI link shouldn't be a bottleneck. But it's hard to know
> for sure; just too many variables.
>
> I guess you could try running a speedtest on your phone while you have a
> ping running from your tethered laptop. Not sure how effective the
> app-based speedtests are at inducing bloat, though; they're certanly not
> measuring it...

Thanks for the suggestion! It seems like I get results that are in line with what I got when running the flent test. I'll contact my mobile service provider as well to check if they're aware of the bufferbloat issue.

Also, if anyone's interested, I found an interesting paper about bufferbloat experienced during uploading on 4G networks: https://www-users.cs.umn.edu/~fengqian/paper/bufferbloat_imc16.pdf

>
> -Toke