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.
