On 23/04/2021 10:12, Malte Appel wrote:
You can find these measurements either in the Built-ins tab of the probe (Ping First Hop / Ping Second Hop).
https://atlas.ripe.net/probes/1001821/#tab-builtins
Or over the API by accessing measurements with ids 1 (first hop, see below) and 2 (second hop).
Ah, perfect, thanks. There was a disconnect between the link previously sent, and the references to #1 and #2, mostly because those measurements don't appear to be listed on that RIPE page! Here are some probes that I spotted on my own Atlas visualiser as having slow access to the DNS root system (~300ms+) followed up by queries to measurements to #1 or #2 to look for very slow last "mile" connectivity: 11268 (DSL, very variable 100 - 900ms) 12803 (4G, /me waves at Eberhard!) 16494 (LTE, variable 30 - 250ms) 20306 (Satellite, 1st and 2nd sub 3ms, root servers 700ms+) 26228 (data not accessible) 27843 (data not accessible) 33110 (untagged, 2nd hop 270 - 420ms) 50592 ("Swisscom SAT Probe", 1st and 2nd hop sub 4ms, root 600ms+) 51871 (FTTH, 1st and 2nd hops sub 2ms, large root latency jump today) 52560 ("FastestVPN", consistent 285ms second hop) 1000244 (untagged, 2nd hop 600ms, occasional drops to 60ms) 1000795 (untagged, very variable, 35 - 1000ms!) For background, the RSSAC Local Perspective WG is looking at measurements of the root system, perhaps using Atlas, but we'd like to be able to establish a baseline figure that we can subtract to account for probes that are on the end of a slow internet access technology. We don't want the figures skewed by these outliers. I'll probably need to do some explicit traceroutes on those where the high latency was not introduced by the 1st or 2nd hop to find out where the latency does happen. I also spotted an odd probe geolocated in the north SF Bay area but with 170ms second hop latency and only hitting root anycast instances located in Europe. It smells like a long distance BGP tunnel to me, but I know the individual that runs that network so I'll check with him. Ray