shane, Firt, you can't use the kernel discipline if the clock runs other than 100 Hz. The Linux kernel apparently does not adjust the kernel phase and frequency coefficients for other that 100 Hz. I have reports that the coefficients have been re-engineered for higher clock frequencies and NTP is happy.
Second, I suspect the kernel adjtime() system call does not correct the slew rate to 500 PPM when the clock frequency is changed. This is not hard to do and requires changing only one define that sets the number of microseconds or nanoseconds adjusted at each tick. I conclude running an unmodifed Linux kernel at other than 100 Hz with NTP is a lose. Dave [EMAIL PROTECTED] wrote: > Hey all, > > I've been experimenting with Linux kernel settings with respect to how they > affect ntpd as I understand for the gps18lvc to work effectively, one needs > a fairly accurate clock. One thing I've found is with hz=100, I'm getting > an ntp.drift of around 40 but with a fairly good rootdispersion at stratum 2 > of approx 15. With hz=250, the frequency drift drops to 15 but dispersion > and jitter rise. Finally, I tried the high-res timers patch with and > without dynamic ticks. The hr-timers have frequency at 0.039but the jitter > reported by ntpq -p on peers is still higher than a vanilla kernel with > hz=100. > > So my question is should the drift be varying so much based on kernel hz and > why would there be increased jitter with a reduced frequency error? Has > anyone else tried the hrtimers patch and had good results? > > Shane > _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
