37

From what I understand, the crystals on PC's 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 anybody had any experience on stackoverflow.com!

I understand NTP is the popular choice, but am wondering if anybody has had any experience with PTP (IEEE1588)

luvieere
  • 37,065
  • 18
  • 127
  • 179
PiNoYBoY82
  • 1,618
  • 2
  • 14
  • 17

9 Answers9

18

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.

wnoise
  • 9,764
  • 37
  • 47
15

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.)

Camille Goudeseune
  • 2,934
  • 2
  • 35
  • 56
  • I really wanted to follow these links but the zx81.isl.uiuc.edu links are dead and scholar.google.com links to http://zx81.isl.uiuc.edu/camilleg/dsceu04.pdf is dead as a result also :( – gazarsgo Oct 01 '15 at 13:45
  • @gazarsgo try this: http://webcache.googleusercontent.com/search?q=cache:Yx34JjoTKBUJ:zx81.isl.uiuc.edu/camilleg/dsceu04.pdf+&cd=2&hl=en&ct=clnk&gl=de – AddingColor May 03 '17 at 13:10
  • Neato, @AddingColor, even if the diagrams didn't survive the conversion to HTML. Anyways, the zx81 links have remained up for a few years. – Camille Goudeseune May 03 '17 at 16:12
  • @CamilleGoudeseune Would this work on the open internet? If so, to what degree of accuracy? (micro/nanoseconds) – rawinput Dec 12 '18 at 18:16
  • @CamilleGoudeseune How do i link with common c++ cause I installed libcommoncpp2-dev with apt ( ubuntu 16) and imported headers normally but the linking is not working : undefined reference to `ost::IPV4Address::~IPV4Address()' – rawinput Dec 12 '18 at 20:59
  • On open internet, accuracy depends on the connections of course. In `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. – Camille Goudeseune Dec 18 '18 at 23:52
  • @CamilleGoudeseune Sorry again, can you give me a number (accuracy in ms ) given a good internet connection like 100/20 mbs stable. – rawinput Jan 03 '19 at 20:17
  • 100 Mbps download with 20 Mbps upload is faster than the 10 Mbps LAN this software was tested with, so "10 microseconds average, 100 microseconds worst case" still holds. – Camille Goudeseune Jan 03 '19 at 20:38
  • @CamilleGoudeseune all these links appear to be dead, are there new ones I should be pointed to? additionally, would your system also work to synchronize two or more smartphones to within millisecond precision/accuracy? – Felipe Mulinari Rocha Campos Apr 14 '20 at 18:05
  • @FelipeMulinariRochaCampos 1, fixed. 2, I haven't tried compiling it on Android or macOS. The dependency on libcommoncpp2-dev might be tricky. – Camille Goudeseune Apr 15 '20 at 16:59
  • @FelipeMulinariRochaCampos libcommoncpp2-dev is no longer needed, so compiling for smartphones should be more attainable. – Camille Goudeseune Oct 22 '21 at 18:51
9

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).

Mecki
  • 125,244
  • 33
  • 244
  • 253
  • 10
    While this answers points out some challenges to a good protocol, the conclusion is completely false. Using NTP you can easily hold machines on a local LAN to sub millisecond precision. Even over the Internet, you can expects to hold time in the say 10 ms range using NTP – Tall Jeff Sep 18 '08 at 23:27
  • 10 milliseconds is not millisecond accuracy as the questioner has requested. You are voting down my question, although I'm the only one trying to stay within the requests of the questioner. And even here on my GBit LAN Ping times vary by more than 1 ms sometimes depending on network load. – Mecki Sep 22 '08 at 09:43
  • 11
    NTP (the protocol) is capable of and can easily hold better than 1 millisecond precision between machines on the same LAN. I voted you down because what you describe is not accurate. – Tall Jeff Sep 22 '08 at 15:18
  • 1
    Mecki, you quoted a link that contradicts yourself, because it says "There are several articles on NTP accuracy. The best of them seems to be one by Dave Mills (the primary investigator on NTP). NTP v4 with kernel mods to support it, is capable of much better than 1ms accuracy, possibly as good as 1ns." I think the way to go is the one xsaero00 says, with that authoritative server having a GPS syn card... – Andor May 05 '09 at 11:51
  • 4
    "According to his article, NTP v3 is accurate to 1-2ms in a LAN and 10s of ms in WAN nets." speaking of the Mills article. Sounds like NOT better than 1ms to me. To get the better quoted results you need "NTP v4 with kernel mods to support it". Unless the linked article didn't summarize the Mills article properly. – Mark Ransom Oct 07 '09 at 22:44
  • 1
    You seem to be assuming it is WAN use case. But question does not say that -- just "between machines", which I would think is as likely to be within LAN than not. So to me it seems that it is quite possible that 1-2ms is quite within "millisecond" accuracy (I do not read that as request to be accurate within fraction of millisecond) – StaxMan May 17 '10 at 19:23
  • @Mecki the link is broken. – rmp251 May 30 '14 at 17:13
  • https://en.wikipedia.org/wiki/Precision_Time_Protocol - of course you can. Its just not cheap. – wishi Mar 09 '16 at 14:38
3

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.

Mike Starov
  • 7,000
  • 7
  • 36
  • 37
2

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. :D

HTH

Lester Cheung
  • 1,964
  • 16
  • 17
2

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

Tall Jeff
  • 9,834
  • 7
  • 44
  • 61
  • Relative to a good source of time, the NTP pool is a good place to start. See www.pool.ntp.org – Tall Jeff Sep 18 '08 at 23:19
  • NTP is not accurate to the millisecond, you are not following the questioners constrains. – Mecki Sep 22 '08 at 09:44
  • NTP (the protocol) is perfectly capable of holding accuracies between machines on a LAN to better than 1 millisecond. – Tall Jeff Sep 27 '08 at 13:21
  • 2
    I used: http://www.meinberg.de/english/sw/ntp.htm when looking for a good NTP solution under windows – Sembiance Jun 26 '09 at 14:32
1

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.)

Chris
  • 4,852
  • 1
  • 22
  • 17
1

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.

nsayer
  • 16,925
  • 3
  • 33
  • 51
1

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.

Ana Betts
  • 73,868
  • 16
  • 141
  • 209
  • Are you sure about this? Could you add some proofs or explanations, please? Thank you. – Cristian Ciupitu Sep 19 '08 at 01:04
  • 2
    I don't have a specific reference, but I do believe the statement is true about reading once. Although, the software real-time clock is probably even a less precise timebase than the hardware one on many machines. Hence the need for an external (say NTP) source. – Tall Jeff Sep 22 '08 at 15:17