Conversation
@jon
Side note: the reason the internet connection experience on most trains is so horrible is not actually a lack of bandwidth. Everything you do with the WiFi on a train would work fine with a couple of Mbps of *reliable* low latency connectivity.
The problem plaguing train connection is terrible reliability and enormous amounts of bufferbloat leading to latency spikes in the tens of seconds. This is what leads to the stuttering and unusable internet experience only too common on trains, not a lack of bandwidth.
Unfortunately, no app I'm aware of measures this correctly. Some speedtest apps have started including latency under load measurements (including speedtest.net) which is a start, but for a train in motion I'd really like a long-running latency measurement that clearly showed the worst case spikes. Plotting it on a map would be cool as well.
Side note: the reason the internet connection experience on most trains is so horrible is not actually a lack of bandwidth. Everything you do with the WiFi on a train would work fine with a couple of Mbps of *reliable* low latency connectivity.
The problem plaguing train connection is terrible reliability and enormous amounts of bufferbloat leading to latency spikes in the tens of seconds. This is what leads to the stuttering and unusable internet experience only too common on trains, not a lack of bandwidth.
Unfortunately, no app I'm aware of measures this correctly. Some speedtest apps have started including latency under load measurements (including speedtest.net) which is a start, but for a train in motion I'd really like a long-running latency measurement that clearly showed the worst case spikes. Plotting it on a map would be cool as well.
5
6
13
@pettter
@jon
Yeah, something that runs a ping in the background and collects the samples with time and location stamps would be pretty instructive, I think. I often do this manually when I'm on a train, by just running a ping in a terminal window, and it is quite common to see it spike above 30 *seconds* of RTT.
If you want to be really fancy you could also have the utility monitor the link for idleness and run a speedtest-like test occasionally to stress test the link over time. But if you're using the connection for other things, that's usually enough to suss out bad latency behaviour, at least with the quality of the connections I've experienced on most trains...
@jon
Yeah, something that runs a ping in the background and collects the samples with time and location stamps would be pretty instructive, I think. I often do this manually when I'm on a train, by just running a ping in a terminal window, and it is quite common to see it spike above 30 *seconds* of RTT.
If you want to be really fancy you could also have the utility monitor the link for idleness and run a speedtest-like test occasionally to stress test the link over time. But if you're using the connection for other things, that's usually enough to suss out bad latency behaviour, at least with the quality of the connections I've experienced on most trains...
0
0
0
@c_chep
@jon
Yes and yes (it seems) :/
A lot of the problem stems from the fact that benchmarks optimise for single stream TCP throughput. And a good way to get a really good score on such a benchmark is to add heaps of buffers everywhere. Which sucks for literally everything else. Yet this is what is still routinely done, even with 5g equipment.
One of the 5G buzzwords is (ostensibly) latency, so at least that has made the industry start paying attention to it as a concept. But I've still seen benchmarks of 5G equipment with seconds of buffering built-in, so it seems more like it'll be yet another benchmark to game: ultra low latency as long as the link is idle, but still bufferbloat out the wazzoo as soon as you run any real traffic on it.
Even my (allegedly) high-class business grade gigabit fibre connection has 30-40 ms of bufferbloat one hop away from me if I don't apply my own traffic shaper. It's infuriating :/
@jon
Yes and yes (it seems) :/
A lot of the problem stems from the fact that benchmarks optimise for single stream TCP throughput. And a good way to get a really good score on such a benchmark is to add heaps of buffers everywhere. Which sucks for literally everything else. Yet this is what is still routinely done, even with 5g equipment.
One of the 5G buzzwords is (ostensibly) latency, so at least that has made the industry start paying attention to it as a concept. But I've still seen benchmarks of 5G equipment with seconds of buffering built-in, so it seems more like it'll be yet another benchmark to game: ultra low latency as long as the link is idle, but still bufferbloat out the wazzoo as soon as you run any real traffic on it.
Even my (allegedly) high-class business grade gigabit fibre connection has 30-40 ms of bufferbloat one hop away from me if I don't apply my own traffic shaper. It's infuriating :/
1
0
1
@toke @jon was recently surprised cloudflare added a boxplot latency graph to its https://speed.cloudflare.com/ - deutschebahn introduced a connectivity-radar in the in-train (ICE) systems for connection quality on the track ahead to plan for that video call, so I'm sure their implementers have the latency data along the highspeed tracks
1
0
0
@c_chep @jon
Well, the WiFi access point inside the train is basically a femtocell, just using a different radio interface. The AP-to-client hop is not usually the bottleneck, though, the train-to-infrastructure hop is. Think of it like a 5G router like you have at home, sitting on top of the train. That's the device that needs to be fixed. Or, well, preferably the whole bloody 5G network...
I actually know of a Swedish company (Icomera) selling connectivity services to trains etc. I believe DB is one of their customers. They have some sort of bandwidth and handover solution which is pretty advanced and they would be perfectly positioned to fix this problem. Unfortunately I have never managed to convince them of the need (it's "not a problem for them" according to the guy I talked to way back when...) 🤷♂️
Well, the WiFi access point inside the train is basically a femtocell, just using a different radio interface. The AP-to-client hop is not usually the bottleneck, though, the train-to-infrastructure hop is. Think of it like a 5G router like you have at home, sitting on top of the train. That's the device that needs to be fixed. Or, well, preferably the whole bloody 5G network...
I actually know of a Swedish company (Icomera) selling connectivity services to trains etc. I believe DB is one of their customers. They have some sort of bandwidth and handover solution which is pretty advanced and they would be perfectly positioned to fix this problem. Unfortunately I have never managed to convince them of the need (it's "not a problem for them" according to the guy I talked to way back when...) 🤷♂️
1
0
0