shane, As I have said before, there are two issues with Linux and clock frequencies other than 100 Hz. First, if the kernel discipline is used, the phase and frequency parameters have to be changed. Othewise, the 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.
So, if you change to other than 100 Hz, do not use the kernel discipline at all. Second, be prepared for some grief using the ntpd discipline loop. The only other advice I can give is use FreeBSD instead. 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
