from Hacker News

Splitting the Ping

by symisc_devel on 3/1/21, 11:15 PM with 51 comments

• by great_wubwub on 3/2/21, 2:50 AM

  Everybody is talking about clock accuracy and totally missing that devices in the middle of the network path do not care about responding quickly to pings. Middle devices are generally routers or firewalls, and their job is to route and firewall, not to respond to a packet as quickly as it comes in. Transit traffic is far more important than processing control plane packets. Devices can add several msec or more in latency by sticking ICMP echo requests and the like in a low-priority queue and getting around to responding eventually. This will dwarf any gains produced by "the best NTP server".

  And no, setting QoS bits on the packet will not help.

• by pxx on 3/2/21, 1:14 AM

  Not entirely related, but a fun and interesting tangent: There's actually no way that we know of to measure the "one-way" speed of light, as the specific synchronization that you use (and this post uses to do its calculation) assumes that the speed of light is the same in both directions. For all we know, light travels infinitely quickly in one direction and at c/2 in the return direction.

  https://en.wikipedia.org/wiki/One-way_speed_of_light

  recent-ish video about this: https://www.youtube.com/watch?v=pTn6Ewhb27k

• by Ono-Sendai on 3/2/21, 12:15 AM

  It's basically impossible to measure the one-way latency, without external information in the form of clock synchronisation done externally. See http://twistedoakstudios.com/blog/Post2353_when-one-way-late...

  This fact is also the basis for special relativity (different observers may choose different simultaneity conventions - for example Einstein synchronisation)

• by nullserver on 3/2/21, 2:27 AM

  https://web.mit.edu/jemorris/humor/500-miles

  Email can’t go father then 500 miles

• by datastoat on 3/2/21, 12:08 AM

  As the article explains, latency and clock sync go hand in hand. Here's a blog post [1] that goes further into clock sync, contrasting NTP and hardware-based systems. The company behind the blog post says that their solution is available as a managed service on Azure and GCP, but I've never looked out for it.

  [1] https://www.ticktocknetworks.com/tick-tock-the-clock-runs-wi...

• by jlgaddis on 3/2/21, 11:22 AM

  If you've got clock synchronization between two hosts, there's OWAMP, a.k.a. RFC4656 [0].

  The Minimum-Pairs Protocol [1] eliminates the need for clock synchronization but requires (at least) 3 hosts under your control, plus the "uncooperative" fourth node:

  > The minimum-pairs (or MP) is an active measurement protocol to estimate in real-time the smaller of the forward and reverse one-way network delays (OWDs).[1] It is designed to work in hostile environments, where a set of three network nodes can estimate an upper-bound OWDs between themselves and a fourth untrusted node. All four nodes must cooperate, though honest cooperation from the fourth node is not required. The objective is to conduct such estimates without involving the untrusted nodes in clock synchronization, and in a manner more accurate than simply half the Round-Trip Time (RTT).

  --

  [0]: https://tools.ietf.org/html/rfc4656

  [1]: https://en.wikipedia.org/wiki/Minimum-Pairs_Protocol

• by jedimastert on 3/2/21, 2:02 AM

  An excellent video about why it's impossible to measure the speed of light in one direction

  https://www.youtube.com/watch?v=pTn6Ewhb27k

• by IgorPartola on 3/2/21, 4:44 AM

  I thought NTP specifically did account for transit latency. Not sure why I made that assumption, but if it’s not true, how can I ever trust my clock to be correct?

• by swinglock on 3/2/21, 6:11 AM

  This protocol and software exists, it's called OWAMP.

• by statstutor on 3/2/21, 12:20 AM

  The article says "Now that we have a synced clock", but surely the clock synchronisation would also be unable to resolve any asymmetry in the ping and the synchronisation would inevitably be impacted by this. (Or, does NTP have a solution to this?)

  [Edited to add: from https://en.wikipedia.org/wiki/Network_Time_Protocol: "Asymmetric routes... can cause errors of 100 ms or more."]

• by dec0dedab0de on 3/2/21, 1:26 AM

  This reminded me of the buffer bloat[0] problem esr was talking about a few years ago.

  I thought I read a paper where he was getting hardware made for the purpose of using gps for time so it could be accurate enough to measure latency. I just googled and I realized it wasn't a paper, it was a talk I went to in 2012 that I forgot about[1]

  I wonder if anything came of it, does anyone know?

  [0] https://hn.algolia.com/?q=bufferbloat (it made the front page more than once)

  [1] https://youtu.be/1b17ggwkR60

• by gerdesj on 3/2/21, 12:39 AM

  "However there is a common assumption on this latency number. Is that you can divide it in half to get the time it takes to send data in one direction"

  So you ssh the other end and ping in the other direction. I tend to use mtr instead.

  Nowadays latency to internet services are within the sort of latencies we used to require on site. OK I do understand that not all internet connections are equal. I live in a fairly rural part of the UK - a small town of roughly 25,000 odd people. The UK is a fairly small country and fairly densely populated and quite rich, so in general: internets are fairly reasonable in comparison to the rest of the world. Not world beating but overall pretty decent.

  If I ping say www.google.com (yes I know it's a funky address with random "distance") from home on my FTTC connection I see something like 15 to 20ms returns. I can ssh the office and use a 1GB link and get 8ms returns. My office PC is on the end of three 1GBs-1 hops in the building itself and it's a crappy old ex-customer hand me down (I run Arch Linux, I don't need whatever W10 requires). Both of those links are via the same ISP. My home PC test is via wifi!

  I'm not going to bother going too much further with this now but if I was bothered (and I will be one day!), I would start my pinging n stuff at my internet facing router.

  It wasn't that long ago that we (my company, about 10 years ago) accepted a condition of contract that required a site latency of 30ms end to end (ignoring hosts - the latency was directly measured without normal IT involvement.) 30ms!