[LinuxPPS] Offset between GENERIC and PPS

[Hal V. Engel]

On Saturday 29 November 2008 12:51:06 David wrote:
> Thorsten Mühlfelder wrote:
> > Hi
> >
> > I'm using 2 ntp servers with Meinberg DCF and GPS cards.
> > http://www.meinberg.de/english/products/gps170pci.htm
> > http://www.meinberg.de/english/products/pci511.htm
> >
> > Additional to the Meinberg NTP driver these cards provide a PPS signal,
> > which is connected to /dev/ttyS1. But as you can see in the following
> > ntpq outputs, there is an offset between GENERIC driver and PPS (~1.7 ms
> > for gps, ~0.6 ms for dcf). Does anybody have an idea how this is caused?
> > Additional question: Why is jitter 0.015?
> >
> > gps:
> >      remote           refid      st t when poll reach   delay   offset 
> > jitter
> > =========================================================================
> >===== LOCAL(0)        .LOCL.          12 l   31   64  377    0.000   
> > 0.000   0.015 +GENERIC(0)      .GPSi.           0 l   10   64  377   
> > 0.000    1.664   0.015 oPPS(0)          .PPS.            0 l   18   64 
> > 377    0.000   -0.046   0.015
> >
> > dcf:
> >      remote           refid      st t when poll reach   delay   offset 
> > jitter
> > =========================================================================
> >===== LOCAL(0)        .LOCL.          12 l   54   64  377    0.000   
> > 0.000   0.015 +GENERIC(0)      .DCFi.           0 l   17   64  377   
> > 0.000    1.391   0.866 oPPS(0)          .PPS.            0 l   34   64 
> > 377    0.000    1.944   0.870
> >
> > PS: I'm using a 2.6.26.2 kernel with patched glibc (nano patches) and ntp
> > build against this glibc (status 0x2001 (PLL,NANO)).
> >
> > _______________________________________________
> > 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
>
> Thorsten
>
> I don't know these cards, I use a Trimble SV-6 providing serial TSIP
> messages and a PPS feed. In my case the delay's around 40ms, but easy to
> explain - the GPS has to send the time at 9600 baud, and so around 40
> characters is around 40 ms. I assume that something has to decode the
> DCF signal, and indeed the GPS calculation won't be instantaneous. Thus
> these clocks will be slow relative to the PPS.
>
> On the parse driver (which appears as GENERIC in ntpdc) fudge time1 is
> used to adjust out these delays - doing so isn't essential, but makes it
> more likely ntpd will continue to believe the PPS. Looking at the
> Meinberg driver time1 seems to be used for the same thing. Thus
>
> fudge 127.127.8.0 time1 0.0017
>
> may improve the gps (assuming it's refclock0). Sorry, can't remember if
> it's +0.0017 or -0.0017 - you'll need to experiment.
>
> No idea on the jitter value.
>
> Cheers
>
> --David
 
Unless your Meinberg clocks have reliability problems like significant periods 
of signal loss that result in needing the LOCAL clock for hold over you 
probably should disable the LOCAL clock in ntp.  Even if this were the case I 
would expect the radio clocks (at least the GPS version) to have a much more 
stable oscillator than the computer and I would be inclined to use the GPS PPS 
for holdover during signal loss if I was concerned about holdover issues.  
Looking at the Meinberg GPS unit specs it has at least a GPS disciplined TCXO 
that should keep free run drift to ± 4.3 msec per day.  This is way more 
accurate then most LOCAL clocks.   The reason I bring this up is that the 
LOCAL clocks could be the source of the higher than expected jitter numbers.

In addition the PPS pulse is probably the most accurate indication of the 
seconds epoch and you should probably configure this as the preferred time 
source since in reality you only have one reference clock (IE. GENERIC and PSS 
are different time feeds from the same clock). 

Hal