Subject: Re: NTP and PPS_SYNC option
To: Greg Troxel <firstname.lastname@example.org>
From: john heasley <email@example.com>
Date: 12/15/2005 16:49:46
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
> 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.