[ntp:questions] Query about NTP accuracy

Unruh unruh-spam at physics.ubc.ca
Sat May 23 05:08:58 UTC 2009


"Richard B. Gilbert" <rgilbert88 at comcast.net> writes:

>Andy Yates wrote:
>> Unruh wrote:
>>> Andy Yates <andyy1234 at gmail.com> writes:
>>>
>>>> Hal Murray wrote:
>>>>> In article <4a15e001$0$18238$da0feed9 at news.zen.co.uk>,
>>>>>  Andy Yates <andyy1234 at gmail.com> writes:
>>>>>> Does anybody have any figures that shows the effect on accuracy of an
>>>>>> NTP v3 client using a stratum 1 server rather than a stratum 2 or 3
>>>>>> server? It's all in a GE LAN based scenario, commercial stratum 1
>>>>>> servers connected to GPS and stratum 2 and 3 servers are typically
>>>>>> dedicated Linux boxes.
>>>>>> However I'm been pressed to supply an SLA for accuracy. My argument is
>>>>>> that although you can get your stratum one server to synchronize to
>>>>>> microseconds of UTP, as soon as the client uses NTP v3 over the LAN,
>>>>>> even a GE LAN, then the accuracy degrades and putting well designed well
>>>>>> specified stratum between the boxes is not going to decrease accuracy
>>>>>> sufficiently to warrant purchasing many stratum one appliances.
>>>>> What sort of accuracy are you interested in?  1 ms?  10 ms?  100 ms?
>>>> Hi Hal
>>>> Its up to us to specify what we think the SLA should be - the guide is
>>>> "as accurate as possible"!
>>> That is of course completely idiotic. They do NOT want it as accurate as
>>> possible. That would cost them millions of dollars and is not in fact
>>> needed. What are they using the time for? what kind of machines are they
>>> ( Windows, linux, BSD, special home grown OS?)
>>>
>>>
>>>>> How stable is your temperature?  (Both the room and the CPU load.)
>>> ntp is terrible if anything varies ( absurdly long settling times).
>>>
>>>
>>>> Temperature will be very stable, the DC is the very well specified and
>>>> scrupulously engineered - no cables blocking air flow etc. Generally
>>>> speaking the CPU is over specified.
>>>>> What is the load on the LAN between the clients and servers?
>>>>> (Delay is not a problem.  Variation in delay is a problem.)
>>>> The NTP will be on a separate management LAN to the production traffic
>>>> so not subject to the variances that application load has on the network.
>>>>> I suggest you measure it.  Start with your current system.
>>>>>
>>>>> Setup a box as a ntpd system and tell it to use several target boxes
>>>>> as servers and turn on logging.  peerstats will tell you the difference
>>>>> between your local clock and the target system.
>>>>>
>>>> I'll look at the current NTP infrastructure however its completely
>>>> different to the new. The old has 3 geographically diverse GPS receivers
>>>> plus a GPS and radio source on the roof of the data centre and we use
>>>> network components to provide the intermediate strata between stratum
>>>> one and client - and have not really had many issues after almost 10
>>>> years of use. However, requirements are changing and we will probably be
>>>> using dedicated stratum 2/3 servers as required.
>>> Does teh GPS have PPS ( puse per second) or are they just using the nmea
>>> time signal? Radio about as bad as GPS with just NMEA for timing. 
>>>
>>>
>> Hi Unruh
>> 
>> it uses IRIG-B but can use PPS amongst others - However I should have
>> said "as accurate as possible using a well designed NTP system". Our
>> stratum zero sources and stratum 1 sources will be v.accurate - its the
>> distribution via NTP that were trying to get our heads around.

>How are you "distributing" NTP?  On a LAN?  On WAN?  What are you using 
>the time for?  Do you have legal requirements for the accuracy of your 
>timestamps?

>It's possible to get all the systems on a LAN to more or less agree on 
>what time it is.  +/- 20 milliseconds should be easy.  +/- 10 
>milliseconds is achievable.  The tighter the agreement, the more it's 
>going to cost you!  Add a WAN and it gets more difficult and more expensive.

Uh, 30usec is more like it. At least that is what I get/got on my lan.


>One of the keys to getting tight synchronization is a stable and 
>accurate source of time.  A GPS timing receiver can supply time of the 
>required quality.  Note that GPS receivers designed for navigation 
>service are generally pooly suited to timing service, and vice versa.

You must have a GPS which delivers PPS, and a good interrupt service
routing to timestamp the PPS transition. 
You must run an operating system like Linux or BSD which actually has
time support (interpolation) in the kernel. 






More information about the questions mailing list