[HN Gopher] Measuring the Earth with Traceroute (2002)
___________________________________________________________________
Measuring the Earth with Traceroute (2002)
Author : signa11
Score : 42 points
Date : 2022-03-16 08:25 UTC (1 days ago)
(HTM) web link (arxiv.org)
(TXT) w3m dump (arxiv.org)
| marcodiego wrote:
| I miss xtraceroute.
| marclundgren wrote:
| Can traceroute be used to _prove_ that the Earth is spherical? Or
| at least show the statistical probability that it is shaped more
| like a sphere than a flat surface?
| xXmontagXx wrote:
| Not sure about definitive proof, but one could trace between a
| few directly-connected nodes i.e. along the pacific rim. Then,
| making the same assumptions as the article (i.e. cables lie
| along great circles, most of the measured time is spent in
| traversing the cable, etc), demonstrate that those connected
| nodes do not lie on a flat plane.
|
| The more nodes one has mapped, (i.e. distance measured to
| surrounding nodes) the less likely one is able to orient those
| nodes into any shape other than a sphere.
| oonerspism wrote:
| I think yes. If we assume reliable conversion of traceroute
| results to implied distances, and can generate selected data
| (routes) of our choice. That is, we can see results of remote
| hops that aren't directly connected to us. Then, ultimately,
| the resulting matrix of results would (mathematically, ++)
| conform to a spheroidal shape and no other.
|
| ++ think Map Projections, and the associated math.
| ad404b8a372f2b9 wrote:
| This is an interesting and fun class exercise but the results
| were much worse than I expected.
|
| I'm reminded of Carl Sagan's Cosmos where he explains how
| Eratosthenes calculated the radius of the earth, to a great
| degree of accuracy, by comparing the shadows of two distant
| obselisks. I wonder if there is a modern equivalent that would
| give similar accuracy by observing side-effects of our telecom
| architecture, or our other very futuristic systems in comparison
| to Eratosthenes' obelisks.
| dtx1 wrote:
| taking a geostationary satellite and measuring the delay it
| takes from two positions and assuming a perfectly round earth
| should get you there
| IfOnlyYouKnew wrote:
| Does graphviz take edge lengths as input? One could let it do its
| magic and should, for correct data, get a map.
|
| (I've used it with street intersection data from Wikidata and it
| came up with a surprisingly good map of Berlin, only mirrored.)
| cproctor wrote:
| In architecture school, my partner had to map a landscape using
| old-fashioned triangulation: using measurements between fixed
| points to build a map of triangles. The problem is, your
| measurements are usually a bit off (e.g. you measure from
| different points on a tree's trunk, the tape was sagging, you
| assume measurements are planar but there is topography, etc. If
| you aren't careful about the order in which you build your map,
| errors compound.
|
| We developed some software to optimize for least squared error
| and then plot points. Not a sophisticated algorithm, but it
| worked well! https://github.com/cproctor/triangulation
| jvolkman wrote:
| One thing about traceroute that I doubt most casual users think
| about (maybe I'm wrong) is that its output only shows you the
| forward path. That is, it shows you the path your packet takes
| from when it leaves your machine to when it gets to the
| destination. The path that a response packet originating at that
| destination and travelling back to you can take a different path
| (sometimes wildly different) and - while you'd see that captured
| in latency - you wouldn't see it captured in the list of routers.
|
| So a packet from Seattle to Hawaii may take the most direct
| undersea cable, but the response packet may be routed through
| California, adding significant geographic distance.
| kemals wrote:
| This comment is spot on. This is asynchronous nature of the
| computer networks. While it is easy to control the path within
| smaller or enterprise networks, it is very likely that the
| reverse path on the internet is going to be different compared
| to forwarding path. Following that, the real challenge is, in
| case that you are dealing with some issue, to detect where the
| issue is, given that it might be happening on the reverse path
| that you don't have visibility into.
| kloch wrote:
| A similar mistake can easily be made when using iperf to
| measure throughput or identify performance problems.
|
| In TCP mode the results reflect a combination of forward and
| return path effects, though the return path usually has less
| effect on total throughput than forward path. Only with UDP
| mode can you accurately measure unidirectional path
| performance.
| justbrandon2u wrote:
| Doesn't traffic and network device CPU load make all this
| hogwash? Just asking for a friend.
| zamadatix wrote:
| It'll add some minor noise but if you suspect it to be at
| significant factor you can effectively completely eliminate the
| noise by picking the lowest values over multiple runs.
| Something like mtr will report jitter statistics for you.
| TorKlingberg wrote:
| I used to do traceroute to addresses far away like Japan or
| Australia to which way it takes. Packets often went through the
| US even when you'd think there's a shorter route.
|
| These days traceroute to a random .jp or .au just gets you to the
| nearest CloudFlare or AWS, which is a bit sad in a way.
| kemals wrote:
| If there was a shorter route and you took longer one you are
| dealing with suboptimal routing :)
|
| However, "is a bit sad in a way" part of sentence is
| interesting one. Edge services hosted within
| AWS/Cloudflare/Akamai improved customer experience
| significantly given that waiting for trans-Atlantic or trans-
| Pacific latencies is not thing any more.
| ugjka wrote:
| Routing is money, ISPs need to pay more for better routing
| nomel wrote:
| > with suboptimal routing
|
| Or, perhaps optimal surveillance [1][2]. I can only assume
| this sort of thing has expanded substantially since then.
|
| 1. https://theintercept.com/2018/06/25/att-internet-nsa-spy-
| hub...
|
| 2. https://tcf.org/content/report/surveillance-without-
| borders-...
| autoexec wrote:
| It just shows how much the internet has changed. Now all our
| online traffic is increasingly being limited to a smaller and
| smaller set of networks/companies. You get less of a "We're a
| community of networks all throwing packets around for each
| other to make the internet happen" feeling and more of a
| "We're just another source of data to mine by a small number
| of cloud services." sort of feeling I guess.
___________________________________________________________________
(page generated 2022-03-17 23:02 UTC)