Brian Utterback <brian.utterb...@sun.com> writes: >unruh wrote: >> Of course my 9 machines with drift rates up to -250. It will depend >> crucially on which kernel David is running on his linux machines. I suspect >> is is older ( one tends not to keep clusters up to date). I used to have >> distributions like his. but not for the past two years. >> >> Anyway 50PPM is not unreasonable. It is also probably unnecessary.
> From my (admittedly incomplete) understanding of the algorithms in >Das Buch, the key issue is that no server may drift at more than >500PPM in order to maintain the correctness proofs. As noted, this is >fudged a bit due to stepping, which appear as arbitrarily large drift >rates to a client, but the idea is that if you do it all at once then >the damage is mitigated Clearly there is not some magic in the number 5x10^-4. Also there is a difference between slew ( the process of changing the rate in order to correct a time offset) and drift ( the amount by which the natural clock rate is out from true time.) Drift is reallyjust a labeling problem. Is one tick a millisecond or is it 1.012549 ms. If this is constant, it can have absolutely no effect on any correctness proof. The problem in ntp is that drift and slew are inextricably intertwinned and the limit is on the combination of drift and slew, when it should just be on slew. >So, this seems to mean that NTP should not be limited to a correction >less than 500ppm, but should not serve time until the drift is less >than that. It should not server time until the rate of change of the rate drops below some value. >Now, as I recall, there is another factor in that the particular >implementation of the kernel loop in the kernel reference code only >guarantees that there is no overflow when the correction is less than >500ppm. Actually, I seem to recall that it may actually overflow and >the largest correction is limited to 500ppm. The kernel code is a whole other can of worms. There is a 512PPM limit in the adjtimex call as I recall. But with a combination of tickadjust and frequency adjust one can program in any drift rate one wants. This does make the programming more complex. >Brian Utterback _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
