[Rpm] Outch! I found a problem with responsiveness

[Christoph Paasch]

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 at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/rpm