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

Cirilo Bernardo cirilo.bernardo at gmail.com
Wed Feb 24 02:00:16 CET 2010


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/8c2a2a01/attachment.htm 


More information about the LinuxPPS mailing list