Triangulate with Ping [closed]

Question

Is it hypothetically possible to triangulate the location within any accuracy of a server at an unknown location by using ping times?

9 computers with location known log on to a multiplayer server. The 10th player (unknown location) arrives. Can the pings to that machine acts as radii of circles on a map and a bunch of circle intersection math take place to narrow the location of the 10th user?

I am guessing it would depend on the correlation between ping and distance from a machine (since packets probably go through so many different routers before reaching location), but could a method like this pinpoint with more accuracy than just doing a lookup of the machine's ISP?

Answer 1

The answer is YES, but with a lot of caveats. Let me re-phrase the question into a more useful form:

Using only Ethernet packets, on an Ethernet network, can you determine the physical cable length from one device to another?

There is a standard called the Precision Time Protocol (PTP), which is used to synchronize clocks of devices on a network. The basic protocol can achieve sub-microsecond accuracy, but there are ways to get accuracy down to 10's of nanoseconds.

Part of this protocol requires hardware-based timestamping of Ethernet packets in order to measure and calculate the "time of flight" of a packet across an Ethernet cable. This time of flight measurement is then used to adjust for any clock skew across the network. In our case, we only care about the time of flight.

While this does work across Ethernet switches and routers, to get an accurate time of flight the switch needs to support PTP and be involved in the measurements. PTP does support the involvement of the switches and routers. Because PTP uses Multicast packets, it won't work over the Internet.

More and more Ethernet controllers support PTP (even some PC motherboards support it), although switch and router support is lagging by quite a bit.

In theory, PTP can do this. In practice, I don't know if you can extract the time of flight data from this clock syncing protocol-- but the data is there. It might require some somewhat custom implementations of PTP, and definately requires switches/routers that are rare or not quite on the market yet. I am also massively generalizing PTP. I know the hardware side of PTP, but there is a lot of software that I don't know completely.

Another alternative to PTP is to use Ethernet Phy's that can measure the length of the cable. It turns out that many Gigabit Ethernet Phy's can do this now, but those features are rarely exposed past the device driver level. The Phy's do this by using time-domain reflectometry, and can also measure the distance to the break in a faulty cable.

The main problem with any of this is that it measures cable length, not physical position. If the cables were measured accurately, and they were stretched in a straight line, then that could determine physical location. But that never happens. It also requires that the network infrastructure is under your control, which it is probably not.

Of course, what I describe is nothing like using Ping times across the internet to get a physical location. I agree with others that this is not going to be very useful, and probably won't get you anything more accurate than what Continent you're on (if that).

Answer 2

This isn't an electircal engineering question, but the answer is No.

Network routing distances over the internet bear little relationship to geographical location.

Two computers in the same city, but connected to the internet via different ISPs may route through a city hundreds of miles away.

Answer 3

No, because ping response delay is not much of a function of distance. It is much more strongly a function of the number of hops (routers and switches) between the two machines than physical distance. The delay of these routers and switches is much longer than the propagation delays over the wire. They are also highly dependent on the exact architecture of the switch or router, the firmware version, the current load due to other packets, and various other parameters that are unpredictable and not a function of distance.

Look at it another way. What would the pure propagation delay be due to distance? The farthest physical distance would the other side of the planet, which is a round trip of about 40 Mm. Let's say the signal propagtion speed thru the cables is about 1/2 the speed of light, or about 150 Mm/s. That means about 270 ms round trip. But, those hops implemented with microwave links would be at the speed of light, or twice as fast. If the signal got bounced off a satelite, the propagation speed is the speed of light, but the path length is now much longer. The same delay could easily be introduced by a few heavily loaded routers in the path.

Yet another way to look at this is what is the cable distance that would cause 1 ms of delay. Again assuming the 150 Mm/s speed in cable, 1 ms would be the equivalent of 150 km of cable round trip, for a distance of 75 km. So just a single ms of slop gives you a 75 km distance error, but the delay in a single router can easily be more than that.

Then there is also the processing delay to receive the ping packet, verify it, build a reply, and send it. That's very fast on a modern mainstream computer, but can be significant on a small embedded system.

For example, I just pinged a small system with the network stack running on a PIC 18F67J60 from my PC. It is about 1 meter away on my bench, but the cables are much longer than that and there is a switch between the two machines. The round trip reply time reported by my PC was 4 ms, which would imply 300 km distance if you assume it was all due to propagation delay on a cable. In reality, I know that most of that delay was processing the ping packet and sending the reply on the PIC. That was with the default payload size, which I'm not even sure what it is. With 128 byte "buffer size" specified to the ping command, the reply time is 11 ms, and with 1024 bytes it is 76 ms.

Answer 4

Even if you could solve the problem of where each node in the route is located, and could assign the switch delays, the variance in the ping times would kill you.

I just did five pings to my server, and got avg = 55ms, stddev 0.896ms

At 1 ft/nS, that is equivalent to 55000000 feet to the server, or 10,000 miles, with an uncertainty of 170 miles.

I am pretty sure my server is not jumping around hundreds of miles between pings!

And your method , even if it worked, which it wouldn't (see jwgr's answer), would only find the user's ISP. I pinged my ISP, got 5mS. So I know I am within a 1000 mile circle 'round the ISP. Not too helpful either.