"Richard B. Gilbert" <[email protected]> writes: >Andy Yates wrote: >> Unruh wrote: >>> Andy Yates <[email protected]> writes: >>> >>>> Hal Murray wrote: >>>>> In article <[email protected]>, >>>>> Andy Yates <[email protected]> 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. _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
