WAN Connection Latency - Geography vs the Internet

The problem with milliseconds is that most people can’t relate to them, so everybody wants zero ms.
A pragmatic presentation is meters - 1ms = 0.343m and 3ms = 1m.

If two musicians are in the same city, but use different ISP(internet service providers) the signal will probably go hundreds of kilometers to the next ISP exchange point and back.
If they share the same ISP and are lucky, the signal will only go tens of kilometers to the city exchange point. In any case, the number of hops is normally more relevant to latency than the number of kilometers.

If we agree that a total end-to-end latency of 20ms is perfectly tolerable and above 50ms is highly problematic, this table gives us some estimate what European cities can play well together.

Transcontinental connections will usually be above 100ms and therefore need a different musical approach. Some exceptionally expensive technologies provide 45ms between EU and US, but that is out of scope for most musicians today.

Barcelona Frankfurt Hamburg Munich Paris
Amsterdam 32 22 52 15 10
Basel 32 32 45 36 23
Copenhagen 40 34 54 18 24
Graz 47 20 83 26 24
Hamburg 71 23 63 62
London 27 13 38 20 8
Munich 30 7 51 17
Nuremberg 28 3 66 7 13
Stockholm 46 24 58 28 34
Vienna 25 15 73 6 22
Zurich 31 24 35 12 22
1 Like

Hi, just wondering about the latency value shown in the house of consorts.
How does this value correlate with a „ping“? I think a ping is both ways. Does it include the router and house-eth-connection to the real computer?
Again: a ping can be done easily without additional equipment to decide wether to be able to play with friends or not; this would base an invest on facts and not only on the wish to stay connected with friends… Am i right?

1 Like

Ping is only a very short package of 32byte, one per second, and realtime audio + video is much more traffic and UDP instead of ICMP like ping or TCP as web traffic. Ping ignores buffer bloat that is a real nightmare for real-time audio. Ping might take different routes every so often, depending on Internet traffic. I still use it as easy best-case measurement, MTR has some improved parameters.
Add fast.com to the mix, since it uses actual real Netflix-payload, so it cannot easily be prioritized by ISPs since they hate Netflix and would rather slow it down than speed it up, as the do with Speedtest.net traffic.
Ping works internally travelling two-way, since there would not be a way to show result times if the packet would not return, but 15ms says 15ms end to end, one-way e2e path but Ethernet only, from socket to socket.
ov-box shows real end to end latency INCLUDING processing in box. You can see this in my measurements comparing actual sound-wave latency to ov-latency.
fast.com also shows you loaded latency, what ping times you get if you create some serious traffic - it’s usually 3-5x ping latency.
To get a step closer to the performance of digital-stage.org, use the command

mtr -rw --tcp digitalstage-router.germanywestcentral.cloudapp.azure.com

tl;dr: If you have ping times to Frankfurt:

<15ms Cool
<30ms ok-ish
>50ms ORDER BETTER INTERNET. Do not try music (faster than [Gregorian Chant](https://en.wikipedia.org/wiki/Gregorian_chant)).

If you use digital-stage-pc or digital-stage-box in p2p mode, no router is involved. You must find out the ip address of your peer and ping her PC. We had ensembles in one city playing all under 7ms. We have also musicians from Berlin and Köln experiencing 7ms between them, so sometimes the ISP gods are gracious.

Very interesting data! In our experience though, low latency is only a required data point, not sufficient. The much more critical value is packet jitter, because the amount of jitter dictates either the amount of dropouts or more likely the size of jitter buffers you need to introduce, and they outweigh real network latency very quickly.

Also, package drops can be a concern depending on your forward error correction strategy (how much additional data to your send).

We found not surprisinly that fibre network here in Munich is very predictable with near no jitter, while the worst case we had was a Vodafone cable internet somewhere in Schleswig-Holstein, where buffering caused batches of packets to be delivered at very high speed, unfortunetely requiring jitter buffers > 20 ms.

1 Like

Jitter is absolutely important, and more difficult to understand predict and to believe.
Most users just don’t believe us when we say Wi-Fi is no good, and cable Internet is so much worse than DSL is so much worse than FTTH.
For the geographic global transmission the jitter is much less important to understand than for the last mile. only when two propagation paths change very often you get additional bad jitter. In general, jitter is always on top, and you must never expect the ping time to be your experience.
I had 180ms loaded jitter vs 15ms unloaded jitter today, as measured with fast.com.

BTW, Currently we don’t use a lot of concealment or FEC but try to be as fast as possible.

1 Like

Deutsche Telekom 5G can do 20ms

After many months of experimenting, I have first ok-ish measurements with meter.net:

Down 	Up 	       Ping (ms)
Mbit/s 	Mbit/s 	median 	jitter
167,3	23,93	25.5	1.2
168,8	29,25	20.0	0.5
134,2	27,30	20.0	1.6
133,5	23,01	21.0	6.4

Regarding the latency values in House of Consort: Those are a close approximation of the true latency from one microphone to the other headphones. It includes:

  • half of ping time (because ping is round-trip)
  • the length of jitter buffers
  • 10ms as an approximation of the hardware delay

I measured the delays in several conditions using external measurements and found a very close match (order of 2 ms).

1 Like

Cloud Service Provider Data Center Locations

unique features:

DigitalOcean

Linode

Ping measurement only poorly reflects true audio streaming latency, mostly because of Buffer Bloat. A good test and article to understand it and some remedies for LAN routers is Bufferbloat Test by Waveform

Some good Statiscs are collected with Speed Test by Measurement Lab

Bloat Wiki - Bufferbloat.net`