Terje Mathisen wrote: > 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. > > Andy, you probably know that several dedicated NTP servers have puny > cpus, so they can't handle too many client? > > Any PC manufactured within the last 15 years, i.e. Pentium and up, is > capable of handling at least 100K clients, so the way I setup the ntp > service at Norway's largest corporation was to have three pairs of > FreeBSD boxes, in three widely separated locations. > > Each pair has one Oncore UT+ timing receiver (capable of 15-35 ns > accuracy) connected to one of the servers, but already configured into > the other server as well, so if we have a server crash, the GPS serial > cable can be moved to the alternate box. > > I also have 3-4 NTP appliance servers, as well as a couple of home-made > units (one TAPR-based Oncore eval board and one Garmin 18 which uses USB > power). Finally there's an Endrun CDMA receiver in the US. > > These "extra" resources are used as backup servers for the six primary > boxes, along with a number of ntp pool servers. > > The key idea is that all six official servers are more than strong > enough to handle the maximum possible load, and with so many independent > clock courses, and 6-way redundancy for every single client machine, the > likelihood of serving bogus time is sufficiently small, even though the > total cost of the setup was very reasonable. > > Terje > > PS. Previous to this setup, all three NTP appliance servers failed at > least once, and failed wrong, i.e. they kept responding but with the > wrong time! Each time this happened, we found one or two critical > servers that had been rebooted, then used ntpdate to pick the bogus > server to step the time, and then refused to listen to the two others > which at that point were "clearly wrong" :-( > > Today we never use ntpdate of course, just regular ntp allowing a single > (large) startup step. Many thanks for all the answers guys - I think I have enough ammunition to negotiate a rational SLA and some good insights into how others engineer NTP it and what to look out for.
_______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
