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 <g...@azul.com <javascript:>> > 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 mechanical-sympathy+unsubscr...@googlegroups.com <javascript:>. >> 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-sympathy+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
