In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] wrote: > feedback loop dynamic response will go nuts. Second, the slew rate of > the Unix tickadj() system call needs to be changed to preserve the > assumed slew rate of 500 PPM. The Linux kernelmongers probably know this > but so far have not made the necessary changes.
The last time that I looked at the code, this was done, but, like ntpq, subject to a "precision" of only one microsecond. That means that the slew rate will be 500ppm for clock periods that are a multiple of 2ms, i.e. 100 Hz, 125Hz, 166.666666.... Hz, 250Hz, and 500Hz. Of these, apart from 100Hz, only 250Hz is sometimes used, but 1000Hz is rather more common, and doesn't have an integral number of microseconds per tick that will achieve 500ppm. (I'm not sure if the repeating decimal frequency can actually be configured acurately, though.) > So, if you change to other than 100 Hz, do not use the kernel discipline This is referring to the first of Dave Mills' comments. > at all. Second, be prepared for some grief using the ntpd discipline > loop. This is referring to the slew rate issue. _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
