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 On Sun, Nov 4, 2018 at 3:09 AM Michael Barker <[email protected]> wrote: > 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. > > On Sun, 4 Nov 2018 at 04:26, Florian Enner <[email protected]> > wrote: > >> Adding to this, synchronization of distributed clocks is very important >> in the embedded/automation world and is usually done using IEEE 1588v2 >> <https://wiki.mef.net/pages/viewpage.action?pageId=29230774> (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 >> >> >> On Tuesday, October 23, 2018 at 6:00:19 PM UTC+2, Todd Lipcon wrote: >>> >>> 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 <[email protected]> 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 >>>> ). >>>> >>>> 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... >>>> >>>> On Tuesday, October 23, 2018 at 5:05:22 AM UTC-7, Himanshu Sharma wrote: >>>>> >>>>> 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 >>>>> >>>> -- >>>> 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 [email protected]. >>>> 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 [email protected]. >> 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 [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- Studying for the Turing test -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
