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

Wed Feb 24 22:14:55 CET 2010

On Thu, Feb 25, 2010 at 3:47 AM, Loretta Goldberg <loretta_1958 at yahoo.com>wrote:

> 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.
>

100 microseconds should not be difficult at all.  You just need to think
about various latencies which can occur and which will increase the jitter.

>
> 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/.
>
>

If packets are sent via ethernet it is best to implement NTP on the device
itself; it does not have to be a full implementation, it only has to respond
to requests as if it were a Stratum 1 server.
If RS422 is used and the driver, like the RS232 driver, behaves like a
terminal connection you should be able to use the NMEA refclock without
modification; otherwise I see no issue with simply feeding the stream to the
shared memory.

> 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?
>
>
Reading a refclock every second helps to gain better statistics on the
sources in a short period of time so NTP can act to synchronize the clocks
sooner.  Once NTP has been running for a while it doesn't matter if it is
polled every 16 seconds or even longer.  So if the refclock is polled only
once per 16s on startup that just means that it will take longer before NTP
can start its work, but it should not affect the overall precision of the
clock.

If you have simulators with the required precision, you can simply use them
to test.  If not but you have the time and resources, you can build a
simulator using hardware such as any number of devices from Rabbit
Semiconductor or the MCB08 from MicroSys (or any number of other
microcontroller boards), an embedded GPS with PPS and other off-the-shelf
components for ethernet or RS422 (but this is still about 1-2 weeks work if
you have all the parts and tools and are familiar with the microprocessor
being used).

> --- 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<http://us.mc513.mail.yahoo.com/mc/compose?to=loretta_1958@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://us.mc513.mail.yahoo.com/mc/compose?to=LinuxPPS@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/20100225/2fbc9b51/attachment-0001.htm 