[LinuxPPS] Offset between GENERIC and PPS

[David]

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