David J Taylor wrote: > "nemo_outis" <a...@xyz.com> wrote in message [] >> I fail to see the value or relevance of "500ppm satisfies 98% of computer >> clocks" if some other number, perhaps 5000 ppm, could satisfy yet even >> more >> than 98% of computer clocks with no downside - as indeed seems to be the >> case! Chrony, whatever its other merits and demerits, is an "existence >> proof" for this proposition. >> >> Regards, > > Oh, simply that have knowledge of how many computers were excluded at a > particular value of maximum drift might allow the NTP designer to make a > better judgement of just where to set that arbitrary 500ppm number. For > example, if 100ppm excluded 50% it would obviously be a poor choice, and
NTP originally had 100ppm as the limit, with the intention that you'd use the OS-level static adjustment call (which has a 100 ppm granularity) to get it into the right neighborhood, i.e. within 50 ppm worst case. NTP would then fine tune the clock the last 2-4 orders of magnitude to lock onto the real UTC time. > it 500ppm includes 99.999% of computers it could be an excellent choice. This is probably approximately correct, i.e. with a population of many thousand machines in our corporate network, I have _never_ seen a system with a clock that has been off by more than 200-300 ppm. The exceptions have always been due to driver issues (lost hardware interrupts) instead of actual clock rate problems. > As it is, in a community of end users perhaps one or two out of about a > hundred have reported problems with NTP as supplied, and it seems a > shame to exclude them if a small relaxation in the tolerance might allow > them to run NTP rather than them having the view "NTP doesn't work". See above: This is almost certainly due to a sw rather than hw bug. It was most often seen when people started using 1000 Hz clocks in Linux instead of the old 100 Hz default. > > No chance of the limit being a command-line parameter, I suppose? It could be, it would mean turning a few core parameters in the control loops into variables instead of constants. Terje -- - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching" _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
