Getting clock difference of 2 servers upto single digit micros (as close as possible)

[Himanshu Sharma]

As the title suggests, consider 2 servers connected via an L3 switch. How can we find the absolute time difference between the clocks running on the servers. I want to go as close as possible. 

Actually syncing the clocks is not possible due to some constraints so I want to know the time difference. Is there any opensource tool I can use readily.

Many thanks in advance

[Gil Tene]

The mean end-to-end (from writing to a socket to reading from a socket), round-trip latency across a modern 10G+ switch can be brought down to 30-40usec on modern hardware with relatively low effort and no specialized equipment (e.g. https://blog.cloudflare.com/how-to-achieve-low-latency/), and can be driven as low as 3-5 usec with specialized hardware and software stacks (kernel bypass, etc) (e.g. http://www.mellanox.com/related-docs/whitepapers/HP_Mellanox_FSI%20Benchmarking%20Report%20for%2010%20%26%2040GbE.pdf). 

A trivial round trip ("what time do you have? [my time is X]" to "My clock shows Y for your request sent at X" [recieved at Z]". would allow you to measure the delta between the perceived wall clock difference between two machines to within the round trip latency. e.g. The difference between the clocks (at the time measured) in the above sequence is known to be (Z-Y) +/- (Z-X). You can use various statistical techniques to more closely estimate the bound when repeating the round trip queries many times and across periods of time. E.g. the amazingly effective techniques used (decades ago) by NTP to synchronize clocks to within milliseconds across wide geographical distances and slow/jittery networks still apply even at low latency scales (e.g. start with something like http://www.ntp.org/ntpfaq/NTP-s-algo.htm or https://www.cisco.com/c/en/us/about/press/internet-protocol-journal/back-issues/table-contents-58/154-ntp.html and dig into references if interested).

Keep in mind that at the levels you are looking at clock skew and drift are very real things. And then there is jitter...

[Todd Lipcon]

https://www.usenix.org/system/files/conference/nsdi18/nsdi18-geng.pdf is also a recent research paper on a similar topic which might be an interesting read if you are interested in time synchronization.

-Todd

On Tue, Oct 23, 2018 at 8:47 AM Gil Tene <g...@azul.com> wrote:

The mean end-to-end (from writing to a socket to reading from a socket), round-trip latency across a modern 10G+ can be brought down to 30-40usec on modern hardware with relatively low effort or specialized  equipment (e.g. https://blog.cloudflare.com/how-to-achieve-low-latency/), and can be driven as low as 3-5 usec with specialized hardware and software stacks (kernel bypass, etc) (e.g. http://www.mellanox.com/related-docs/whitepapers/HP_Mellanox_FSI%20Benchmarking%20Report%20for%2010%20%26%2040GbE.pdf). 

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Florian Enner]

Adding to this, synchronization of distributed clocks is very important in the embedded/automation world and is usually done using IEEE 1588v2 (PTP) which can get to sub-microsecond levels. A lot of microprocessors have hardware support for it, but I have never looked into how difficult it'd be to get running on a server.

- Florian

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.

[Michael Barker]

Not sure if helps, but a colleague of mine wrote a series of block posts about the PTP implementation that we used to meet a suite of regulatory requirements.

https://www.lmax.com/blog/staff-blogs/2016/04/08/solving-mifid-ii-clock-synchronisation-minimum-spend-part-7/

Mike.

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.

To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-symp...@googlegroups.com.

[Greg Young]

So there is a well known protocol for this (determining relative clocks) from a rather unusual source... chess servers! Many people enjoy playing chess online very quickly (say 1 minute per side), when playing such quick games a small latency difference can make a huge overall difference so it becomes necessary to take latency of the connection into play.

You can find an implementation here https://github.com/fbergo/zseal

Studying for the Turing test