Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

As far as I know, accuracy of NTP syncronization highly depends on the network. I've seen some numbers from 50 microseconds to a "below one second" over the internet. Well, this is a huge difference.

I believe, accuracy dependence is a great question to study, but so far I failed to find any material, which clearly states that, say, some particular configuration grants that particular accuracy.

It is said on

A time difference of less than 128ms between server and client is required to maintain NTP synchronization. The typical accuracy on the Internet ranges from about 5ms to 100ms, possibly varying with network delays. A recent survey[2] suggests that 90% of the NTP servers have network delays below 100ms, and about 99% are synchronized within one second to the synchronization peer.

With PPS synchronization an accuracy of 50µs and a stability below 0.1 PPM is achievable on a Pentium PC (running Linux for example).

That's something, but maybe there is some more thorough analysis on the topic?

share|improve this question
Whilst I think this question shows no research effort at all, and am downvoting on that basis - it's not even clear the OP has read any of the material on - I do think it's a lawful question, and would argue against closure on that basis. Wanting to know why a protocol will work as advertised, instead of blindly deploying and hoping for the best, isn't a waste of time. – MadHatter May 17 '13 at 12:10
Thanks for updating the question, I've recanted my downvote. That said, you may feel it's annoying to be sent back whence you came, but if you don't tell us where you've been when you ask the question, how can we know? I also note that the very text you post above includes a pointer to an academic paper studying the accuracy of NTP servers. Did you read that, and if so, can you indicate why that wasn't enough? – MadHatter May 17 '13 at 12:40
Fair enough. The paper is an 14 years old overall survey on NTP network. It has further links, but all of them are, of course, even older. I've tried Google Scholar and CiteSeer, but most of the links are the same Mills and Millnar works from the nineties. I'm still browsing, but I am a bit far from the topic, and this might take a lot of time, so I choosed to ask the community for help. – akalenuk May 17 '13 at 12:55
NTP hasn't changed in at least 14 years, why would it's accuracy have changed significantly?? As mentioned below, NTP is not meant to be super accurate, it's meant to get within 1s (which is probably where that underinformed quote came from). If you need sub 1ms accuracy then you'd want to use PTP. I really can't see any value in studying the accuracy of something that in very wide deployment does exactly what it was intended to do. – Chris S May 17 '13 at 13:09
Actually, Chris, the two pieces of work quoted make it clear that the accuracy of NTP servers on the internet (not the protocol itself, which was always excellent) has improved between 1999 and now. I suspect this is partly because the internet's better - latencies are somewhat lower and much less variable than once they were - and partly because the quality of S1 servers has improved (the 1999 paper says that the single most common clock source for S1 servers is the OS clock!). I'm glad the OP asked this question, I think it's worthwhile. – MadHatter May 17 '13 at 13:28
up vote 8 down vote accepted

No-one can guarantee how well NTP will work on your network, because no-one knows how well connected your network is to the internet, and to the clock servers thereon. However, according to the clock discipline algorithm page on

If left running continuously, an NTP client on a fast LAN in a home or office environment can maintain synchronization nominally within one millisecond. When the ambient temperature variations are less than a degree Celsius, the clock oscillator frequency is disciplined to within one part per million (PPM), even when the clock oscillator native frequency offset is 100 PPM or more.

Note that large-but-stable latency between your LAN and the internet's clock servers doesn't have as bad an effect on accuracy as highly-variable latency.

You don't say where you got the estimates above ('50 microseconds to ... "below one second"'), so I can't comment on them, but in my experience 50us is unlikely unless you have a directly-attached clock source, and 1s is unlikely unless you have a piece of wet string connecting you to the internet and you're using upstream servers in Antarctica.

Edit: the text you now quote in your question gives a pointer to a paper which, in 1999, did indeed establish that 99% of ntp servers are synch'ed to within one second. Fortunately, there is more recent work; in this paper some authors from the Federal University of Parana, Brazil, repeated the experiment in 2005, and found (if I understand their Fig. 1 correctly) that north of 99% - more like 99.5% - of servers now have offsets less than 100ms, and that 90% have offsets less than 10ms. This fits in pretty well with my experiences (see above).

Edit 2: one last wrinkle: all these studies don't investigate how accurate local clock is, but instead how far it differs from the upstream reference clock. These are patently not the same thing. But the first is unknowable; to know how wrong your clock is, you have to know exactly what time it is, and if you knew that, why would you have set your clock wrong in the first place? Just be aware that what these studies are measuring is not the difference between local clock and absolute time, but between local clock and reference clock.

share|improve this answer
+1 I ran a pool server as well, >20ms drift monitored clear across the country was odd. – Chris S May 17 '13 at 13:11

What problem are you trying to solve?

The solution I've encountered for environments requiring more precision than NTP is the Precision Time Protocol (PTP). I've had it in scientific computing and financial computing applications. There are tradeoffs, though.

Also see: ptp time synchronization on centos6/rhel

share|improve this answer
"What problem are you trying to solve?" My favorite question - I ask it all the time. – mfinni May 17 '13 at 13:23
@mfinni, When you need to rank which of your clients submit first (e.g. HFT), it helps to be accurate with your time. – Pacerier Dec 20 '14 at 12:35

A few other things worth mentioning:

  • You'll be lucky to get < 100ms of clock jitter on a virtual machine, so all the below is for a physical host
  • Sub 100ms jitter is nearly immeasurable for almost every task, and easily achievable over the Internet
  • Sub 30ms jitter may be needed for some general serving environments (I needed it for log correlation at a previous job), and is easily achieved using NTP servers on the same continent where the connection is not via "consumer" links (eg, not satellite, ADSL, DOCSIS, GPON, UMTS/LTE/HSPA/etc)
  • For absolute accuracy below this you should be installing hardware NTP servers from a quality vendor (eg, Symmetricom)
  • Sub 10ms (often sub 1ms) local agreement can easily be achieved by simply having a trio (you can do with less, but there's reasons to use three or five) within the same datacenter enough for pretty much every non-Science application
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.