Thu, Dec 15, 2005 at 08:10:09AM -0500, Greg Troxel:
> I don't really understand the PPS API, but there are two separate
> things lurking here:
> 
>  driving the system time off the hardware clock.  This can be
>  frequency, where the system clock advances at the rate controlled by
>  the PCI hardware clock, rather than the normal counters.  Or, it can
>  also be phase where the PCI clock provides absolute time.  There has
>  been talk of "timecounter" support being added to NetBSD, and this
>  may relate.
> 
>  Using a 1 pps signal to discipline the local clock (which is
>  conventional) in the kernel, or to take precise on-second snapshots
>  of system clock time for NTP to use in the PLL to adjust the system
>  clock.
> 
> If the first is implemented and in use, I'm not sure of the value in
> the second.  But, the second approach may end up being less invasive,
> at least in some cases.

I do not think I fully understand the PPSAPI either.  Looking at com(4),
and the RFC, it seems to exist for userland; to make PPS events available
to userland and provide the ability to adjust PPS parameters, including
which source (if any) calls hardpps().

Once I fixed an omission in the bancomm reference clock driver this
morning, we find that the kernel offset narrows much more quickly and
with far less bouncing around.  With our serial-fed CMDA clocks (w/o PPS),
this takes far longer, upwards of an hour, even for an event as momentary
as restarting ntpd.

the clock on this particular MB is heinous.  A reboot usually looses at
least a few seconds.  To the point that, in order to recover in any
reasonable timeframe, we added a wrapper that takes the timestamp from
the reference clock, calls settimeofday(), then starts ntpd.