[ntp:questions] Attn Linux distributors - pse include PPS

Rob nomail at example.com
Sun Apr 27 18:17:24 UTC 2014


William Unruh <unruh at invalid.ca> wrote:
> On 2014-04-27, Rob <nomail at example.com> wrote:
>> William Unruh <unruh at invalid.ca> wrote:
>>> But those modules give timing to one a few (5-10) usec. because of
>>> interrupt handling issues. Your shm solution would seem to me to be more
>>> than adequate for any timing requirements if they can be solved with an
>>> interrupt driven pps. 
>>
>> Well, the kernel PPS API does the timestamping in the interrupt handler
>> while my gpsd/SHM solution does timestamping in a user process that is
>> marked to be ready to run in an interrupt handler.
>
> ?? I do not think so-- the kernel has interrupt handlers which stamp the
> PPS input via interrupt routines. They hand the result to gpsd which
> puts it into an shm, if I understand correctly. Thus both the kernel and
> gpsd use the same interrupt timestamping. 

That is a later version, not the one I wrote.  It requires kernel PPS API,
which mine didn't.  That one is still used when kernel PPS API is not
available.  It uses the TIOCMIWAIT ioctl.

The GPS I use (actually a GPSDO) cannot work with gpsd.  It has 1PPS
and 10MHz outputs but no serial datastream other than some very limited
interface that can be used for monitoring.  It does not provide time/date.

So we use ntpd with a couple of network clocks and the 1PPS with the
ATOM refclock (refclock 22).  That works OK.  At least when ntpd is
compiled correctly.

>> Especially on a loaded system it can be less accurate due to scheduling.
>> I experimented with marking the process for realtime scheduling, but
>> the disadvantage is that it hangs the entire system when it goes in
>> a loop due to some bug.
>>
>> On my system the offset and jitter for kernel PPS from a professional
>> GPS receiver (Datum) are usually 1 or 2 microseconds in the ntpq display,
>> but always less than 5.
>
> Yes, that is consistant with what I found with my own interrupt handler.
> I got the feeling but have not done any real tests, that the serial port
> pps (eg
> /lib/modules/3.10.28-desktop-1.mga3/kernel/drivers/pps/clients/pps-ldisc.ko.xz) 
> routine was a bit more ragged.) Or is this module what you mean by
> kernel PPS? 

Yes that is what I use.  PPS timestamping in the kernel, with the PPS API.



More information about the questions mailing list