I’m trying to illustrate a point about latency, the current state of the art, and the minimum theoretical latency possible (i.e. speed of data transfer in electrical wiring).
I have some good data for ping times from London to New York (from when I had access to super-JANET), but I’m aware there are significant differences between cross-atlantic times (one very long straight cable) and cross-continent times (potnetially lots of networks to cross, jumping up and down on backbones, etc).
Is there anyone with access to fast national bandwidth on a continental level? e.g. anyone at a major university?
Especially interested in west-coast US to east-coast US ping times, and anything that stretches from one side of continental Asia to the other, ditto (to a lesser extent) Europe.
The distances need to be large to demonstrate the point, so you really need to be on the edge of your continent, not the middle I’m afraid.
I remember there are some sites that do ping times between internet exchanges, but these don’t tend to be very far apart, and I would prefer to get some data that are within grasp of the consumer, since this is a book on networking in games…
I have remote access to a Win2K3 machine in Athens, on the backbone of one of the two largest greek ISPs. I’m not a networking guy, but given clear instructions (or preferably a nice batch file) I can run a couple of tests.
Pick a city as far away as you can think of whilst still on the same continent (I guess you could try Moscow?).
Work out something in that city that’s going to have a fast connection. Universities are usually good, or else large international organizations.
Best of all is ISP’s based there, if they’re big.
Then you need to:
find out the distance in kilometres (to within 10% of accuracy is fine. Most distances between any pair of cities are availalbe on the web). I can try this myself if you can’t be bothered
run “traceroute name.of.site”.
That could be “tcptraceroute” or it could be “tracert” depending upon your OS.
From the trace, I’ll be able both to verify what I’m looking at and to see roughly whether it’s a realistic route to take.
PS: traceroute is a loverly tool for network coding. It tells you where every packet goes on it’s way to wherever you’re trying to get to - it’s a list of machines that forwarded your packets. Useful for discovering which part of the net is slowing down your packets, whether your ISP is being cheap and paying too little for their international peering, etc.
ISP in Portugal
Athens - Lisbon : 2848 km (1770 miles)
Tracing route to www.oninet.pt [195.245.176.109]
over a maximum of 30 hops:
1 <1 ms <1 ms 14 ms hsrp71-csw01.core.internet.gr [62.1.0.193]
2 <1 ms <1 ms <1 ms fasteth10-noc01.core.internet.gr [62.1.0.1]
3 2 ms 1 ms 2 ms 193.92.29.65
4 5 ms 3 ms 2 ms titan-fa4102.forthnet.gr [194.219.227.129]
5 4 ms 4 ms 3 ms core-ath-02.forthnet.gr [194.219.227.99]
6 73 ms 80 ms 75 ms Pos3-0.GW1.LND8.ALTER.NET [146.188.66.29]
7 92 ms 78 ms 70 ms ge6-0.cr2.lnd8.gbb.uk.uu.net [158.43.188.2]
8 71 ms 70 ms 71 ms pos4-0.cr2.lnd10.gbb.uk.uu.net [158.43.253.150]
9 74 ms 71 ms 70 ms sc-7-0-0.xr2.lnd9.alter.net [158.43.150.102]
10 70 ms 72 ms 77 ms so-1-1-0.TR1.LND9.ALTER.NET [146.188.15.37]
11 112 ms 112 ms 112 ms so-0-1-0.XR1.LIS1.ALTER.NET [146.188.2.226]
12 117 ms 112 ms 114 ms 313.ATM0-0-0.GW1.LIS1.ALTER.NET [146.188.10.106]
13 115 ms 115 ms 115 ms onitelecom.customer.ALTER.NET [146.188.53.254]
14 113 ms 115 ms 116 ms SP01-02 [195.245.137.58]
15 115 ms 113 ms 113 ms fn1.net4b.pt [195.245.191.100]
16 119 ms 116 ms 119 ms www.oninetspeed.pt [195.245.176.109]
ISP in Ireland
Athens - Dublin : 2852 km (1772 miles)
Tracing route to home.eircom.net [159.134.198.138]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms hsrp71-csw01.core.internet.gr [62.1.0.193]
2 <1 ms <1 ms <1 ms fasteth10-noc01.core.internet.gr [62.1.0.1]
3 2 ms 1 ms 1 ms 193.92.29.65
4 3 ms 2 ms 3 ms titan-fa4102.forthnet.gr [194.219.227.129]
5 4 ms 3 ms 3 ms core-ath-02.forthnet.gr [194.219.227.99]
6 72 ms 81 ms 70 ms Pos3-0.GW1.LND8.ALTER.NET [146.188.66.29]
7 70 ms 78 ms 71 ms ge6-0.cr1.lnd8.gbb.uk.uu.net [158.43.188.194]
8 72 ms 71 ms 74 ms pos1-0.cr1.lnd10.gbb.uk.uu.net [158.43.253.137]
9 74 ms 72 ms 72 ms sc-7-0-0.xr1.lnd9.alter.net [158.43.150.98]
10 73 ms 73 ms 76 ms so-0-1-0.TR1.LND9.ALTER.NET [146.188.15.33]
11 73 ms 76 ms 75 ms POS1-0.BR1.LND9.ALTER.NET [146.188.7.242]
12 73 ms 79 ms 78 ms 146.188.35.138
13 75 ms 72 ms 73 ms sl-gw22-lon-1-1.sprintlink.net [213.206.128.103]
14 73 ms 76 ms 74 ms sle-einet-2-0.sprintlink.net [213.206.156.210]
15 88 ms 92 ms 87 ms 159.134.125.46
16 93 ms 89 ms 87 ms 159.134.198.138
I live in the Boston area, but my home comcast cable connection may not be what you want. Let me know, also give me a good destination. I tried microsoft but am getting many Request Timed Out. It might not be a good day for this.
Thanks, spasi. Unfortunately, your international connectivity is not good: everything of yours is going via the UK, at which point it starts to get difficult to estimate the actual distance being covered.
I guess that’s a fair point, though: people who don’t live in the UK or USA will always get artificially inflated ping times.
[quote]I tried microsoft but am getting many Request Timed Out. It might not be a good day for this.
[/quote]
MS always shows up with crap connectivity. Either they deliberately fake their site is slower than it is (to throw off the script kiddies: they think they have enough to DDos, and then fail miserably) or just because they don’t spend enough on their websites.
I seriously doubt the latter ;).
UK and US Universities are nearly always good targets - most have private high-speed backbones, so they’re easy to get at.
Call me crazy, but it seems a little strange to equate geographic distance with “network” distance, that is, how far you have to travel along wiring, and more importantly, how many network devices you have to travel through before getting to your destination.
I must say, this is highly unscientific. It would be much more useful to talk to someone at an ISP who might actually have knowledge of the network topology at the backbone level, and then how it’s split up back the other way to their customers.
I’ve had friends using the same ISP as me, in the same city, who I can’t play online games with because we’re essentially “too far away” in terms of number of hops (over 30) as evidenced by tracert - yet this isn’t the case all the time, sometimes we’re only 10 or 20 hops away.
Even then, the network latency can be unpredictable due to the current level of traffic.
If you’re simply interested in ping times from backbone to backbone, then you might be able to get something reasonably close to reality, but what good would that data do you? How many people using your code are going to be directly connected to a backbone?
Minimum theoretical latency could only be calculated if you knew the actual performance of each device along the path of your network connection from one place to another. In which case, you’d have to know the manufacturer and model number of each device - information which I have a feeling is impossible (not to mention impractical) to obtain. Besides, given the redundant structure of the Internet, each time you test you could be taking a different route through the network. Even if you did a tracert before and after your ping, and even if the route was the same, there’s still no way to guarantee that the path for the both tracert’s was the exactly the same at the moment of your ping request, and no way to determine the amount of other traffic going through those devices at those moments in time.
Hell, even pinging 127.0.0.1 will vary each and every time you do it. Of course if you’re running a platform that won’t show you sub-millisecond precision, then you might not realize this.
[quote]Call me crazy, but it seems a little strange to equate geographic distance with “network” distance.
[/quote]
The point of this is to demonstrate how close the current backbone accessible to anyone with a fast starting point (i.e. paid-for connectivity) is to the limits of non-quantum physics.
A lot of people know Moore’s law. An awful lot of people (especially in games dev) design based on Moore’s law, and a lot games wouldn’t be developed if they didn’t trust it.
But life is very different indeed with latency, even with all the willpower in the world. It’s not even like CPU’s, which reached the limits of known basic wiring some years ago and had to find new fabrication processes: you can use physical distance to compare ping times to the speed of light. The only way to beat this is to make use of physics that doesn’t obey “nothing can move faster than light” (hence quantum physics, which appears to be unbounded by this).
I appreciate your sentiments, but it only looks that way because you didn’t know what was being tested.
I have. They give grossly conflicting answers, or answers that put them in a favorable light. e.g. UUnet has removed the page where they used to tell the world what their transatlantic latency was each month. This is commercially sensitive information that ISP’s are getting more embarassed about and less honest about :(.
One of the nice things about this test is that anyone can reproduce it, assuming they have decent connectivity, and know what they OUGHT to be getting.
You wouldn’t believe how many people spout BS about trans-atlantic transfer rates, for instance. I’ve had tens of people (network professionals) assure me the maximum transatlantic bandwidth using TCP is a few hundred kB/second or similar. Shrug. So much BS, and too few people who can independently verify such things (how many people have high multi-MB/s intercontinental bandwidth to play with?)
This is very interesting, because it oughtn’t to be happening. I was aware of the problems of internet AS-level routing causing stupidly long routes occasionally, but you’re the first person I’ve met who’d been seriously hampered by such mistakes (I was looking at a lecture the other day which gave a real-life example of two nodes on the same semi-private network but also connected via a public higher-bandwidth network, with packts all being routed via the latter, even though contention was higher and the total geographical distance the signals had to travel was over 50 times greater, so that the actual performance was vastly inferior (and contributed to further degradation of the public route that everyone else was trying to use!).
