David Woolley wrote: > I'm not familiar with frequency scaling, but I would suggest that if > the kernel interrupt rates are not constant, ntpd also won't be > entirely reliable. Dave Mills complains from time to time that the > Linux kernel doesn't adjust the kernel PLL parameters correctly when > the clock rate is varied from 100 Hz to another fixed rate, so I very > much doubt that the kernel PLL code has been correctly modified to > cope with a dynamically variable interrupt rate. > > There is also an issue that the fixed speed code rounds things in a > way that only certain rates are safe. > > The kernel interrupt rate is a better indication of what really > matters (except that it will read low if you are losing interrupts) > than HZ, if there is any systematic difference between them. > > If a developer for that code doesn't raise their head here, now, I > think it pretty much safe to assume that the machine is not suitable > for ntpd use for anything except a pure client with low time quality > expectations. Basically, if the developers are not monitoring this > news group, it is almost certain that they not properly taken into > account ntpd's needs.
As a user of ntpd on Linux, I find it disheartening to hear that Linux kernel hackers do not work more closely with NTP hackers. (It'd be nice to have PPS support in the vanilla kernel.) The latest patches to kernel/time/ntp.c can be seen here: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.23.y.git;a=history;f=kernel/time/ntp.c _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
