From: Christoph Paasch <cpaasch@apple.com>
To: Simon Leinen <simon.leinen@switch.ch>
Cc: Christoph Paasch via Rpm <rpm@lists.bufferbloat.net>
Subject: Re: [Rpm] Outch! I found a problem with responsiveness
Date: Mon, 11 Oct 2021 14:01:20 -0700 [thread overview]
Message-ID: <YWSmIMsC4fRd77dd@MacBook-Pro-2.local> (raw)
In-Reply-To: <m1r1czno5j.fsf@switch.ch>
Hello Simon,
On 10/05/21 - 23:43, Simon Leinen via Rpm wrote:
> Hallo Christoph,
>
> > That's right. BB is a transient problem that is extremely short-lived.
>
> > Having tried for the past year to reliably demo the user-visible
> > impact of bufferbloat, I have learned two things:
>
> > 1. When it happens, it is bad - really bad.
> > 2. However, it is very difficult to trigger it "on-demand".
>
> I seem to be able to trigger it quite reliably by using mobile data
> while traveling on the train and doing normal remote work. Here in
> Switzerland I often see RTTs in excess of 10 seconds. In France I have
> seen more than two MINUTES.
wow! Were you able to trace it down? (like, on which device it happend)
> Maybe I should start setting up systematic measurements. For example,
> if I just sent pings both from my laptop to a well-connected fixed host,
> and vice-versa, while capturing all ICMP packets on both ends, I should
> be able to learn about bufferbloat in both directions.
Having tried to debug some bufferbloat problems in a complex
enterprise-network, it is extremely hard to pinpoint where the bufferbloat
happens.
Especially on such kind of a train network, where there is possible either a
VPN or GRE-tunnel involved to get the data out on the Internet...
If you have macOS Monterey, you could run the networkQuality tool to see how
much bufferbloat there is.
Cheers,
Christoph
> It would be even better to have this in a mobile (web) app that could
> record/send location data from the mobile node, to spot the regions
> (presumably around tunnels and other connectivity-challenged areas)
> where the problem tends to occur most often. Alternatively, correlate
> the probe timestamps with real-time location data provided by the
> railway company.
>
> Cheers,
> --
> Simon.
> _______________________________________________
> Rpm mailing list
> Rpm@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm
next prev parent reply other threads:[~2021-10-11 21:01 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-04 23:23 Matt Mathis
2021-10-04 23:36 ` [Rpm] RPM open meeting tuesdays 9:30-10:30 Dave Taht
2021-10-05 15:47 ` Matt Mathis
2021-10-11 20:52 ` Christoph Paasch
2021-10-05 16:18 ` [Rpm] Outch! I found a problem with responsiveness Christoph Paasch
2021-10-05 21:43 ` Simon Leinen
2021-10-11 21:01 ` Christoph Paasch [this message]
2021-10-12 7:11 ` Sebastian Moeller
2021-10-05 17:26 ` Stuart Cheshire
2021-10-05 22:01 ` Matt Mathis
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/rpm.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YWSmIMsC4fRd77dd@MacBook-Pro-2.local \
--to=cpaasch@apple.com \
--cc=rpm@lists.bufferbloat.net \
--cc=simon.leinen@switch.ch \
/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