Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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 http://www.ntp.org/ntpfaq/NTP-s-algo.htm:

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

closed as not constructive by SvW, ThatGraemeGuy, Tim Brigham, Greg Askew, gWaldo May 17 '13 at 17:30

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

2  
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 ntp.org - 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
    
See my updated answer below. That was linked from my second page of google answers, but hey, glad to help. And it is an interesting question. –  MadHatter May 17 '13 at 12:57
1  
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
show 1 more comment

3 Answers 3

up vote 6 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 ntp.org

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.

I run an NTP pool server, and I generally find that its offset from upstream is less than 10ms; you can see the graphs on my munin page, if you want (this is for the ipv4 upstream servers; the munin plugin doesn't seem to want to work for the ipv6 servers).

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 run a pool server as well and hitting >20ms variation from a monitor clear across the country is odd. –  Chris S May 17 '13 at 13:11
add comment

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
2  
"What problem are you trying to solve?" My favorite question - I ask it all the time. –  mfinni May 17 '13 at 13:23
add comment

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
add comment

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