From: Michael Yartys <michael.yartys@protonmail.com>
To: "Toke Høiland-Jørgensen" <toke@redhat.com>
Cc: Simon Barber <simon@superduper.net>,
"make-wifi-fast\\@lists.bufferbloat.net"
<make-wifi-fast@lists.bufferbloat.net>
Subject: Re: [Make-wifi-fast] Bufferbloat on Norwegian train wifi
Date: Wed, 24 Jun 2020 08:56:47 +0000 [thread overview]
Message-ID: <AoYRdUZ0pEQfEYqVt8TaeFFPy-t6bH9-u-JemXQm0GMxmmvgzPIBRsc0Q8PNs4BjHz4lSklZFPkfUwNe44pXXAEJpsv2V-Uu-Du0vxRG7TY=@protonmail.com> (raw)
In-Reply-To: <87o8part1d.fsf@toke.dk>
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, 23 June 2020 12:11, Toke Høiland-Jørgensen <toke@redhat.com> wrote:
> Michael Yartys michael.yartys@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
prev parent reply other threads:[~2020-06-24 8:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.607.1592728703.24343.make-wifi-fast@lists.bufferbloat.net>
2020-06-22 12:51 ` Toke Høiland-Jørgensen
2020-06-22 20:29 ` Simon Barber
2020-06-22 21:14 ` Michael Yartys
2020-06-23 10:11 ` Toke Høiland-Jørgensen
2020-06-24 8:56 ` Michael Yartys [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/make-wifi-fast.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='AoYRdUZ0pEQfEYqVt8TaeFFPy-t6bH9-u-JemXQm0GMxmmvgzPIBRsc0Q8PNs4BjHz4lSklZFPkfUwNe44pXXAEJpsv2V-Uu-Du0vxRG7TY=@protonmail.com' \
--to=michael.yartys@protonmail.com \
--cc=make-wifi-fast@lists.bufferbloat.net \
--cc=simon@superduper.net \
--cc=toke@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox