On Thu, Nov 20, 2014 at 12:02:06PM +0100, Miroslav Lichvar wrote: > On Thu, Nov 20, 2014 at 10:16:13AM +0000, David Taylor wrote: > > Running the sleep 10 sequence from a command procedure gives a difference of > > 1055, so I guess that's 105.5 interrupts per second. Does sound like 100 > > Hz, yes. > > > > Running the command while another terminal was running "cat /dev/urandom > > > /dev/null" resulted in 1063 interrupts, so 106.3 Hz. > > > > Does that mean I'm tickless or not? > > It seems it's not running in the tickless mode and the problem with > zero jitter is caused by something else. > > Do you have PPS kernel discipline enabled in your ntpd config (flag3) > and which driver do you use? The PPS discipline is always disabled > when the Linux kernel is compiled with NO_HZ, so I think that could > explain what you are seeing. I'm not sure if that would be an ntpd bug > or kernel bug, but I can look into it.
After some debugging it seems the problem is that ntpd configured to use the PPS kernel discipline enables it even when the kernel consumer binding failed with the ENOTSUPP error (as would happen with a kernel compiled with NO_HZ). ntpd thinks PPS is running and is using the PPS stats for the clock jitter. This was broken somewhere between ntp-4.2.4 and ntp-4.2.6. I've attached a patch to the ntp bug #2314. -- Miroslav Lichvar _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
