Pages in this thread: 
Print Thread
No, I said already the server has changed.
Manchester (Xilo) no longer points to 91.199.78.82, it now points to 31.193.12.35. I stated this clearly in my previous post:
I know; that's why I deliberately repeated the traceroute to the IP address you gave (rather than the resolved name for their Manchester speedtest server, or 31.193.12.35).
I was trying to replicate the times you saw (albeit with slightly different routing) and did, indeed, do that (showing around 3ms difference between a server you've already stated is definitely in London and 91.199.78.82 (where ever that IP is, it's likely not to have moved far, as the timings are pretty much the same).
There wouldn't have been a lot of point me doing a traceroute to a server now based in Manchester, to prove (either way) the timings from London to somewhere near London (the point being to see how far away, in terms of typical commercial traffic, that server is likely to be from - I guess - the north-east end of Docklands), and at 3ms (give or take) it's fairly close to London - most likely either Maidenhead or Milton Keynes (if, indeed, it's still a Xilo server at 91.199.78.82).
Given the timings you've mentioned from London to Manchester (6-8ms), 91.199.78.82 is unlikely to be more than 100km from Docklands (Maidenhead and MK are both within that distance).
OK - I misunderstood what you were getting at. Sorry. It appears we're in general agreement - 91.199.78.82 is not in Manchester, and as it resolves to speedtest.xilo.net it's almost certainly another Xilo server. Traceroutes show traffic going via mhd.uk.as44574.net so one can reasonably assume mhd stands for Maidenhead so it's probably the Maidenhead server.
It all goes back to a comment I posted a while back (something along the lines of "how come my ping to Manchester is 10ms, yet pings to MK - around 30 miles away - are 26ms, unless BT is doing some weird-ass routing, or the Manchester server isn't in Manchester").
EDIT: Or how come pings to Manchester are the same as to Coventry (with Coventry less than 30 miles up the road and Manchester something like 130 miles away - does data really go 100 miles in zero ms).
EDIT2: Another oddity - Paris 10ms, Manchester 10ms, London 26ms (surely the Paris data goes through London on its way out of the country).
This is why we need to use traceroutes (and several of them) to accurately determine latency and paths, rather than just relying on the Speedtest.net flash app. Web based tests can be highly inaccurate, and some Speedtest.net servers show consistently higher or lower pings than actual.
Right now, Manchester seems to be one of them - these speedtests show my ping to be 9ms 8ms and 9ms again while the real ping is 12ms:
C:\Users\Administrator>ping 31.193.12.35
Pinging 31.193.12.35 with 32 bytes of data:
Reply from 31.193.12.35: bytes=32 time=12ms TTL=58
Reply from 31.193.12.35: bytes=32 time=12ms TTL=58
Reply from 31.193.12.35: bytes=32 time=12ms TTL=58
Reply from 31.193.12.35: bytes=32 time=12ms TTL=58
Ping statistics for 31.193.12.35:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 12ms, Maximum = 12ms, Average = 12ms
C:\Users\Administrator>hrping -s 25 -n 100 -q 31.193.12.35
This is hrPING v3.13 by cFos Software GmbH -- http://www.cfos.de
Source address is 0.0.0.0; using ICMP echo-request
Pinging 31.193.12.35
with 32 bytes data (60 bytes IP):
Statistics for 31.193.12.35:
Packets: sent=100, rcvd=100, error=0, lost=0 (0.0% loss) in 2.487892 sec
RTTs of replies in ms: min/avg/max/dev: 11.021 / 12.630 / 19.763 / 0.993
Bandwidth in kb/sec: sent=2.411, rcvd=2.411
Similarly on my home connection Speedtest says 37ms while command line ping shows a little over 40:
C:\Users\Administrator>hrping -s 10 -n 100 -w 1000 -q 31.193.12.35
This is hrPING v3.13 by cFos Software GmbH -- http://www.cfos.de
Source address is 10.1.1.1; using ICMP echo-request
Pinging 31.193.12.35
with 32 bytes data (60 bytes IP):
Statistics for 31.193.12.35:
Packets: sent=100, rcvd=100, error=0, lost=0 (0.0% loss) in 1.030660 sec
RTTs of replies in ms: min/avg/max/dev: 39.680 / 40.352 / 41.466 / 0.413
Bandwidth in kb/sec: sent=5.821, rcvd=5.821
London (Namesco) is a server that does the opposite - with web results always showing much higher pings than actual - 66ms 68ms and 67ms while the real pings is actually 34ms:
Statistics for gonzales.namesco.net:
Packets: sent=100, rcvd=98, error=0, lost=2 (2.0% loss) in 49.534376 sec
RTTs of replies in ms: min/avg/max/dev: 33.888 / 34.345 / 43.325 / 1.020
So my real ping to the London server is 34ms but Speedtest.net says 68ms
and my real ping to the Manchester server is 40ms but Speedtest.net says 37ms.
Basically, Speedtest.net web results for pings are inaccurate, and can be much higher or lower than the real result.
Course, there is things like weird routing as well. The Preston server for example is hosted on Virgin Media's network, so anyone on VM near Preston will get a low ping - but someone on BT in Preston will get a higher one as their traffic goes via London and back again.
Also, shorter/longer distance does not necessaries mean shorter/longer pings. On VM for example, it takes longer to get from London to Birmingham than it takes to get from London to Manchester. The Birmingham link takes 8ms RTT, but Manchester is only 6ms. So people in Coventry (on VM) get a higher ping to London (1ms to Birmingham + 8ms to London) than someone in Manchester (6ms).
A worse example, Virgin Media also have a "direct" fibre link from Manchester to Amsterdam - 500km as the crow flies - with a round trip time (ping) of about 26ms.
But on BT, Manchester to London then London to Amsterdam takes 15ms total, and that's 625km. 25% longer distance, but still 40% lower latency. That's an extreme case though, VM's Manc => Ams link is exceptionally slow as far as modern networks go
And once recently a bad route caused traffic to France to go via New Jersey and Amsterdam. It happens all the time - and traceroutes will help you figure out how and why.
So anyway
1) Speedtest.net results can be completely whack
2) Longer distance does not necessarily equate to higher ping (but there are physical limits)
3) The shortest or most obvious route is often not the one your data actually uses.
Edited by deleted (Wed 09-May-12 01:31:20)
!