[time-nuts] GPS for ntp

Dennis Ferguson dennis.c.ferguson at gmail.com
Tue Oct 21 17:29:45 EDT 2014

On 21 Oct, 2014, at 08:58 , Simon Marsh <subscriptions at burble.com> wrote:
> How do you map the timer counter value in to a PPS timestamp ?
> (that is, how do you turn the HW counter value in to what the OS thought the time was when the event occured ?)

On the NetBSD prototype I have the clock adjustment system call
interface is expanded to deal with multiple clocks, only one
of which is the system clock.  The HW counter becomes its own
clock, which is the clock in which PPS measurements are expressed
and which is adjusted into alignment with the PPS data.  The
system clock is adjusted into alignment with the HW counter clock
using offset data from PIO polling of the clock pair.  The IEEE1588
timestamp counter becomes a third clock, which gets adjusted into
alignment with the system clock for use as a PTP server, or which
is used to adjust the system clock when operating as a client.

For the beaglebone this is probably overkill; since the clocks
are all synchronous the system<->peripheral clock polling essentially
determines a constant offset, after which you can keep them in sync
by making the same relative rate adjustments to all clocks.  For the
general IEEE1588 case, however, the counter being sampled at the
ethernet interface is often clocked by a different crystal then the
clock you would prefer to use as the system clock, and the process
of steering one clock into synchronization with another needs to be
more complex.

I should note that none of these clock adjustments really requires
a PLL or other feedback control loop, nor does NTP, since no clock
hardware is actually adjusted. The crystals are all free running and
are unaffected by the adjustments. What is adjusted is instead a
"paper clock", that is the adjustment is to the arithmetic done to
convert each free running counter to a time of day, and this can be
done open loop, with perfectly predictable results and with no
feedback control, by just doing the adjustment arithmetic accurately
and transparently.

The thing the PLL does for ntpd, then, is to allow it to deal with
(paper) clock adjustment interfaces which don't do the arithmetic
accurately, or at least don't tell you what they actually did, so
that the arithmetic done can only be determined by further
measurement.  This is unavoidable if you need to deal with a
big variety of operating systems, I guess, but it does make
the problem harder than if the adjustment interface is fixed and
feedback loop eliminated, leaving just the measurement problem.

Dennis Ferguson

More information about the time-nuts mailing list