[LinuxPPS] Processing PPS through NTPs shared-memory reference clock

Wed Feb 24 17:47:35 CET 2010

In answer to the questions below:

1.  My time keeping requirement is to synchronize to within 100 microseconds of the  time coming from the GPS
2. The shared memory reference clock is refclock #28 within ntp.  It uses the shared memory mechanisms originating from Unix System V (requiring /sys/ipc.h and /sys/shm.h).  This ntp reference clock driver allows the timestamp from any GPS to be written to a shared memory location.  When the reference clock is configured (ntp.conf), the shared memory location for the clock is read via the reference clocks poll function.

The gpsd daemon uses this reference clock to interface to ntp.  In their documentation they recommend setting the minpoll and maxpoll values to 4 in ntp.conf, forcing the polling interval to 16 seconds.  However, in ntp4.2.5p138, the shared memory clock code was modified to read the shared memory location every second.

I found a reference for an experiment using a Garmin GPS, http://time.qnan.org/.  The author used GPSD for the processing of the NMEA, and a shmpps daemon for the processing of the PPS.  Unforturately he grabbed whatever NTP was available at the time of his experiment, and doesn't know what release he used.

3.  The GPS I am writing code for, does not yet exist.  To some extent I am being asked to theorize what I will be able to do.  I have a simulator that has be written to send time-of-day packets via RS422 or ethernet.  These packets will be processed via a daemon external to NTP, writing the timestamps to the shared memory location.  The pulse-per-second will also be processed external to NTP, the associated timestamp will be written to a second shared memory location, as was done via shmpps in http://time.qnan.org/.  

I was looking for some insight as to the impact of reading the shared memory location every second (ntp4.2.5p138) vs. once each 16 seconds (ntp4.2.4 - the release I have to work with).  Using the shared-memory interface, ntp doesn't really know that one of the timestamps is a PPS and the other is a TOD.  The daemons outside of NTP are looking at the timestamps, and not sending the PPS onto NTP until the time has been synchronized with the TOD.  The reference clock associated with the PPS is declared as the "prefer" time source, such that NTP will synchronize to it, when it is passed on to NTP.

Is it a pipe dream to think that I can experiment, prior to having the real GPS, as to what I can do with a set version of Linux and ntp?

--- On Tue, 2/23/10, Cirilo Bernardo <cirilo.bernardo at gmail.com> wrote:

From: Cirilo Bernardo <cirilo.bernardo at gmail.com>
Subject: Re: [LinuxPPS] Processing PPS through NTPs shared-memory reference clock
To: "Loretta Goldberg" <loretta_1958 at yahoo.com>
Cc: linuxpps at ml.enneenne.com
Date: Tuesday, February 23, 2010, 6:00 PM

1.  What are your timekeeping requirements?
2.  What is this shared memory reference clock?
3.  What GPS is it that has no NTP reference clock implemented?

Your question about how a modification will affect the accuracy of your time estimate cannot be answered without knowing exactly what modifications are made and how they work and without comparison to a reference clock with known characteristics (for example, have a look at the test setups described by many people).

 The accuracy you can gain from a particular GPS really depends on so many not necessarily obvious things.  For example, a GPS communicating with an RS232 transceiver can give fairly low jitter and pretty good timing even without a PPS signal provided you can employ a number of tricks (which you can't because of your restriction on modifications). However, even a stock RS232 transceiver + GPS can result in sub-millisecond accuracy; in comparison the USB based GPS interface will usually have much higher jitter thanks to the USB protocol. If you want to know if a newer version of the NTP reference implementation yields better results, you need to look at the comments in the changelog; at any rate that is more a question for the NTP lists than for linuxpps.

 It doesn't matter if your reference clock updates at a much higher rate than the polling interval; that is normal operation for most clock sources using NTP.  NTP looks at reported times, gathers statistics, and uses various algorithms to slowly adjust the computer's clock rate to synchronize with the reference sources.  Attempting to update the clock rate too frequently is a very bad thing.  If you look at the description of how NTP works, it polls less frequently as the algorithms determine that certain requirements have been met.

On Wed, Feb 24, 2010 at 11:14 AM, Loretta Goldberg <loretta_1958 at yahoo.com> wrote:

I have both a pulse-per-second signal and a time-of-day message coming from my gps.  The pulse-per-second will be designated as the "prefer" instance of the shared-memory reference clock.  The time stamp for the pulse-per-second will not be passed to NTP until NTP has "locked on" to the time stamp coming from the time-of-day message.

I have a GPS for which a reference clock does not exist, so I have to write an external app, and pass the time to NTP via the shared-memory reference clock.

My restrictions are RHEL as is, no adding the PPS support to the kernel.
ntp4.2.4p4 as provided by Redhat (no changes allowed).  I know that the shared-memory reference clock was modified  for (ntp-4.2.5p138) to collect data each second, rather than once per polling interval.  

What would be the impact of this modification on how accurately I can estimate the current time from a given GPS?  

If my system requirements specify that I have to use a version of NTP that predates this modification, can I attain the same accuracy from my GPS?

Is the limitation that it will take me longer to synchronize to my GPS?  Or does the increased polling interval prevent me from attaining the same degree of accuracy in my estimation of the current time?

_______________________________________________
LinuxPPS mailing list
LinuxPPS at ml.enneenne.com
http://ml.enneenne.com/cgi-bin/mailman/listinfo/linuxpps
Wiki: http://wiki.enneenne.com/index.php/LinuxPPS_support

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://ml.enneenne.com/pipermail/linuxpps/attachments/20100224/f3d373de/attachment.htm 