From what I understand, the crystals on PCs are notorious for clock skew. If clocks are always skewing, what is the best way to synchronize clocks between machines, with millisecond accuracy and precision? From what I've found, NTP and PTP are possible solutions, but I was wondering if anyone else has had any experiences with PTP (IEEE1588).
Just run the standard NTP daemon.
It does have options to take input from several GPS devices as well as talking to network servers.
Edit: I was referring to http://www.ntp.org/, not the one that comes with Windows.
I don't have any suggestion as to what NTP clients are best for windows, but for Unix machines there's no real reason to not run NTP.
Here's some 15-year-old software that syncs to within a hundredth of a millisecond. (My team wrote it when NTP wasn't good enough for our lab.)
From the conference paper's abstract: "A distributed clock for networked commodity PC's. With no extra hardware, this clock correlates sensor data from multiple PC's with latency and jitter under 10 microseconds average, 100 microseconds worst case."
Source code: https://github.com/camilleg/clockkit
(Until 2020 Feb 13 it was at http://zx81.isl.uiuc.edu/clockkit/, now offline.)
clockkit.conf
, tweak the settings for phasePanic and updatePanic. To link, try removing -fPIC
from the makefile. That and a few tweaks to #include's got it running on Fedora 23. –
Totalitarian You cannot synchronize machines to the level of milliseconds by exchanging data, because any data exchange itself already takes at least milliseconds to happen and thus spoils your result! Even protocols that try to first measure how long a data transfer takes and then sending out the time info (taking the measured delay into account) are just a bit better than average but they are still not good since not every data transfer takes equal time (just constantly ping a server on the Internet and see how every ping has a different delay).
The only way to really synchronize two computers in the milliseconds range is by having them both obtain the time from the same source via a transfer method that has no unknown or constantly changing delay. E.g. if both receive a satellite signal, that broadcasts the time. The signal will always have a constant delay (from satellite to earth) and they are both receiving it almost within the same nanosecond.
Germany for example has a radio controlled time. Somewhere in the country is an atomic clock (that has correct time to the nanosecond for hundreds of years) and some sender permanently broadcast the current time on a given frequency all over the country. Alarm clocks and even wristwatches exist that can receive this time and permanently synchronize with it (well, not really permanently, most models do that only once every 24 hours to save battery runtime). Such receiver devices also exist for computers and come with software that can permanently synchronize your computer clock with that time signal.
As far I know GPS also sends time information (either that, or the time can be calculated somehow from the GPS information, I'm not too familiar with the GPS protocol). So attaching a GPS receiver to both computers can probaly also get them synchronized to the millisecond. If your synchronization is done via the Internet however, don't expect a better synchronization than one computer being at most 20 milliseconds off.
To update on the commenter,
NTP is not that accurate as people love to claim here:
NTP can usually maintain time to within tens of milliseconds over the public Internet, and can achieve better than one millisecond accuracy in local area networks under ideal conditions.
Source: Wikipedia
I would rather keep them all in sync without any network involved and farther keeping them in sync to the official GMT time and here GPS is probably the only way to get really accurate results on all machines (and that not only down to the ms, actually down to microseconds).
I use NTP throughout the whole network at my company and it works rather well. The key is to have one authoritative server on a local network and have every machine on the network synchronize with it. The best is to have a radio clock installed on that server. NTP is great because it does not just correct the clock once in a while, but it actually calculates and correct clock frequency making it more accurate.
Once I had NTP setup on the network I opened like five VNC session to different server and sat there watching the clock. The clocks on all server were in sync withing milliseconds, and this is right after setup. It gets more accurate as it runs.
Solutions based on NTP or SNTP can work very well, but it strongly depends on how well the client is implemented.
Certainly, the answer to this question is not to use the default Windows time service if you want sub second precision. It is notoriously poor at maintaining a stable time base on a machine and will typically overshoot corrections and is almost unstable even, especially when machines have fairly inaccurate timebases to start with - which is common. Assume the standard built in Window's tools can hold accuracies reliably there to typically only several seconds between all machines and I typically see swings of as much as 30 seconds between machines - even if you tweak the registry settings.
The freeware tool Achron is a pretty good solution to get down into the plus/minus 500 millisecond kind of range. Doing better than that will require a more industrial strength solution such as something from Greyware
I've researched (read Googled) on this topic lately and here is what I have learn so far:
To get millisecond-accuracy (or better) you need hardware support. GPS source or hardware time-stamping (and a good time source) in PTP.
Hardware time-stamping in PTP is done with supported NIC - Intel has them.
Without hardware time-stamping the accuracy between NTP and PTP are similar.
(Not used PTP before) I read that NTP is easier to setup.
My limited experience with GPS time source (over serial) varies. It works great if you can get it to work but there is a device that we have in a data center that I never managed to get it to work...
If your machines are in colo ask your DC what they can provide - so you don't have to decide.
NTP is definitely the way to go. Basically fire-and-forget, as long as you let it out the firewall on your local master (which is typically the firewall or router machine.)
As you've already suggested, NTP is the industry standard solution to this problem, but it either requires Internet connectivity or a stratum 0 source (an accurate hardware clock, like a GPS receiver with a computer interface).
If you're using Internet connectivity, consider using the NTP Pool.
Keep in mind as well, that the hardware system clock (i.e. the inaccurate one) is only read when the machine starts up - if you're talking about server machines, you're not going to lose time because of them.
© 2022 - 2024 — McMap. All rights reserved.