[ntp:questions] Query about NTP accuracy

Andy Yates andyy1234 at gmail.com
Sat May 23 00:41:17 UTC 2009


Richard B. Gilbert wrote:
> 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.
> 
> 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.
> 
The bit that matters is on a LAN and the kit is all designed for NTP -
Symmetricon or similar. I'm not worried about that side of it, its just
that we've never needed to push NTP LAN distribution this hard before
and wanted to get wider user experience. I won't go into what we in much
detail do but its uses "real time systems" and time matters.




More information about the questions mailing list