[time-nuts] GPS for ntp

[Simon Marsh]

Thanks for the great explanation.
Is there any data on the performance ?

Cheers


Simon


On 21/10/2014 22:29, Dennis Ferguson wrote:
> 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
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.