3 ms·
Fun read, I learned a lot! Thanks for writing. I’m curious if you used three or more probe servers in distinct locations if you might be able to roughly triang
by tbenst 7y ago
Fun read, I learned a lot! Thanks for writing.
I’m curious if you used three or more probe servers in distinct locations if you might be able to roughly triangulate server location?
To increase accuracy, seems the underlying topology should ideally be taken into account. Probably more work than it’s worth, would it be cool to have some kind of skeleton for the wires, to calculate distance metric with higher accuracy than an arc.
- mirimir 7y agoThanks :) 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 agoAlso, 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 agoYes, 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