Bounding the target platforms

[Hal Murray]

esr at thyrsus.com said:
> The immediate issue is whether we can drop RFC1589 support in favor of
> RFC2783.

RFC1589 describes an in-kernel PLL that synchronizes the system clock to an 
external PPS signal.

RFC2783 describes the API for user code to read the time stamps for a PPS 
signal that the kernel grabs at interrupt time.

Short version:
  RFC1589 works well.  With Linux you have to build a kernel.
  I don't think we should remove anything until we have good data to verify that we have a better alternative.

----------

Long version:

The way that ntpd uses RFC1589 is to get everything ready, then flip a switch to pass control to the kernel.  While the kernel PLL is active, ntpd just watches to verify that things look good.  If something goes wrong, it can turn off the kernel PLL and go back to normal mode.

Some/many OSes/distros don't ship a kernel that supports the in-kernel PLL.
In particular, it isn't available in Linux when compiled with NO_HZ.  I think that is an implementation detail rather than anything fundamental.  NO_HZ saves power on idle systems.  It's important for battery life on laptops.

Some/many OSes have rewritten (or just tweaked) the in-kernel PLL.  Maybe the new code is better.  Maybe it's just different.  Maybe it isn't stable.  (Dave Mills worked hard to make sure things didn't overflow and/or that the parameters chosen wouldn't oscillate.  It's easy to make PLLs oscillate.)

The API described in RFC2783 has an option to wakeup when new data is ready.  ntpd doesn't use that.  It just polls.  I don't know how many OSes implement that wakeup.

I think it is likely that we would get results similar to the in-kernel PLL if we copied the code to user-land and called it as soon as the PPS data was available.  That would require the wakeup option.  This would be an interesting cleanup of the overall system (OS+NTP) but it would add code to NTP.

I don't see any way to cleanup ntp by moving that sort of code to a driver connected by SHM.  We could probably do it with a pipe, but it would be complicated and ugly.

--------

We should work on a NO_HZ version of ntpd.

Has anybody collect battery life data on a laptop with and without ntpd?

ntpd wakes up every second and checks a bunch of things.  Most of those things just bump a counter and return.  The code could peek ahead or use callbacks to figure out when the first real work will happen and setup the wait-for-packets select to wait that long rather than 1 second.

I don't think that will help any if we are using refclocks.  (We might be able to setup something like a GPS that only sends data every N seconds.)



-- 
These are my opinions.  I hate spam.