4 ms·

Thanks :) It was fun to do, as well. Although often tedious. I played some with triangulation, with no joy. From the SE thread "Triangulate with Ping [closed]

Thanks :) It was fun to do, as well. Although often tedious. I played some with triangulation, with no joy. From the SE thread "Triangulate with Ping [closed]"[0] I get that it's impossible. Latency depends more on device delays than on distance. Within densely populated continents, router/switch count does depend more or less on distance. But there's too much variability. Or at least, none of the models that I tried converged. It might be doable, with enough information about Internet structure. So you could deconvolute device count and distance. But that would be a lot of data, and I have no real clue where to get it. The NSA? 0) https://electronics.stackexchange.com/questions/68619/triangulate-with-ping https://electronics.stackexchange.com/questions/68619/triang...

myself248 7y ago
Also, a lot of circuits take paths that don't show up on traceroute, because the IP packets are just a payload bitstream riding another transport that doesn't interact with them, doesn't decrement TTL, et cetera. It's quite normal to have a router in Toledo talking to a router in Detroit but the packets ride a transparent SONET circuit to Chicago and back, so the two hops look 50 miles apart but are about 500 fiber-miles apart with consequent speed-of-light delays. And the folks who play at the IP router level are often entirely ignorant of the layers below, to much confusion. (I worked on these systems for years. A conversation with another network admin about this ignorance became the genesis of the Anything But Ethernet contest, which we ran for several years at a midwest tech con. Hijinks ensued.) Learning anything about the layers below, that don't interact with IP packets, is gonna be hard, I concur. You're flying blind except for speed-of-light, and have a lot of other delays to solve out. "Might be doable" is about my conclusion, too. You'd need a whole crapton of probes, with accurate locations, and a whole crapton of math, which is way over my head. I feel like the equations are gonna start to resemble the way GPS works, but that's the thing — GPS does work! My gut feeling is that it's worth a try.
- mirimir 7y ago
  Yes, I've seen stuff like that. In a guide for IVPN a couple years ago, I looked at a few examples more carefully. I say more about that in this subthread.[0] One of their network engineers helped me understand what was going on with their servers in Zurich, Reykjavik and Salt Lake City. As I recall, we found that two of their Swiss servers, in different data centers, had no direct peering. One peered with the other via Milan. I also played around with placing my own probes, using VPS hosting that peered with VPN server hosting. Using information from https://bgp.he.net/ https://bgp.he.net/. But that's too tedious for general use. In this work, I basically ignored it. And focused on testing for plausible signal velocity. Still, I do agree that it's an interesting problem. Maybe I can learn enough to make it doable. 0) https://news.ycombinator.com/item?id=21932436 https://news.ycombinator.com/item?id=21932436

myself248 7y ago

Also, a lot of circuits take paths that don't show up on traceroute, because the IP packets are just a payload bitstream riding another transport that doesn't interact with them, doesn't decrement TTL, et cetera. It's quite normal to have a router in Toledo talking to a router in Detroit but the packets ride a transparent SONET circuit to Chicago and back, so the two hops look 50 miles apart but are about 500 fiber-miles apart with consequent speed-of-light delays. And the folks who play at the IP router level are often entirely ignorant of the layers below, to much confusion. (I worked on these systems for years. A conversation with another network admin about this ignorance became the genesis of the Anything But Ethernet contest, which we ran for several years at a midwest tech con. Hijinks ensued.) Learning anything about the layers below, that don't interact with IP packets, is gonna be hard, I concur. You're flying blind except for speed-of-light, and have a lot of other delays to solve out. "Might be doable" is about my conclusion, too. You'd need a whole crapton of probes, with accurate locations, and a whole crapton of math, which is way over my head. I feel like the equations are gonna start to resemble the way GPS works, but that's the thing — GPS does work! My gut feeling is that it's worth a try.

mirimir 7y ago
Yes, I've seen stuff like that. In a guide for IVPN a couple years ago, I looked at a few examples more carefully. I say more about that in this subthread.[0] One of their network engineers helped me understand what was going on with their servers in Zurich, Reykjavik and Salt Lake City. As I recall, we found that two of their Swiss servers, in different data centers, had no direct peering. One peered with the other via Milan. I also played around with placing my own probes, using VPS hosting that peered with VPN server hosting. Using information from https://bgp.he.net/ https://bgp.he.net/. But that's too tedious for general use. In this work, I basically ignored it. And focused on testing for plausible signal velocity. Still, I do agree that it's an interesting problem. Maybe I can learn enough to make it doable. 0) https://news.ycombinator.com/item?id=21932436 https://news.ycombinator.com/item?id=21932436