is it part of some common js lib?
AWS data center latencies, visualized
201–210 of 223 posts
Re: AWS data center latencies, visualized
#202The data is really useful, and the globe is visually impressive, but it feels like it'd be more practically useful to have a flat world map that shows all the data centers at once and makes it easier to read the lines without them getting excessively close to each other.
A 2D world may not give you the perception of how far some of these locations really are. I think an option to switch between the two would be better.
Re: AWS data center latencies, visualized
#203The data is really useful, and the globe is visually impressive, but it feels like it'd be more practically useful to have a flat world map that shows all the data centers at once and makes it easier to read the lines without them getting excessively close to each other.
Author here - Cool and useful is a careful balancing act.
Re: AWS data center latencies, visualized
#204How did you choose which datacenters to include? For example, eu-south-2 (Spain) is missing. The reason I know is because I worked on a project that required latency to be under 30ms between datacenters, and we had to use eu-west-1 (Ireland) and eu-south-2. Turns out that latency is closer to 42ms, mainly because there are no undersea cables between Ireland and the continent (they only go to England, then they have t…
Re: AWS data center latencies, visualized
#205How did you choose which datacenters to include? For example, eu-south-2 (Spain) is missing. The reason I know is because I worked on a project that required latency to be under 30ms between datacenters, and we had to use eu-west-1 (Ireland) and eu-south-2. Turns out that latency is closer to 42ms, mainly because there are no undersea cables between Ireland and the continent (they only go to England, then they have t…
How do you know there aren't any cables between Ireland and the main European continent? I'm genuinely curious where this is published.
https://www.submarinecablemap.com
This will show you everything connected to Ireland:
Re: AWS data center latencies, visualized
#206It would be really cool if it didn't just show the ping, but how much worse it is compared to the theoretical optimum (speed of light in fiber optic medium, which I believe is about 30% slower than c). I raise this because I've been in multiple system architecture meetings where people were complaining about latency between data centers, only to later realize that it was pretty close to what is theoretically possible…
Doesn't look like this is a ping[0]! Which is good. Rather it is a socket stream connecting over tcp/443. Ping (ICMP) would be a poor metric. [0] https://github.com/mda590/cloudping.co/blob/8918ee8d7e632765...
Re: AWS data center latencies, visualized
#207Earlier quoted context omitted.
Doesn't look like this is a ping[0]! Which is good. Rather it is a socket stream connecting over tcp/443. Ping (ICMP) would be a poor metric. [0] https://github.com/mda590/cloudping.co/blob/8918ee8d7e632765...
why 443? are you assuming ssl here? serious question, I'm not sure. But if it is, wouldn't it be hard to disregard the weight of SSL in the metric?
Re: AWS data center latencies, visualized
#208Earlier quoted context omitted.
The 'practical' way to beat fiber optics is to use either (i) a series of overground direct microwave connections (often used by trading firms) (ii) a series of laser links between low altitude satellites. This would be faster in principle for long distances, and presumably Starlink will eventually offer this service to people that are very latency sensitive
Low-bandwidth/low-latency people tend to also demand high reliability and consistency. A low-orbit satellite network might be fast but, because sats move to quickly, cannot be consistent in that speed. Sats also won't ever connect data centers other than perhaps for administrative stuff. The bandwidth/reliability/growth potential just isn't there compared to bundles of traditional fiber.
Satellites in geostationary orbit are a (very common) thing.