On 21 Oct, 2014, at 08:58 , Simon Marsh <subscripti...@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@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.