[ntp:questions] using both a PPS source and a HBG (dcf-77-like) timesource?

Folkert van Heusden folkert at vanheusden.com
Tue Jan 15 13:52:15 UTC 2008


> >Well if I remember correctly someone said to me once that the
> >time-string returned by cheap gps device (like my garmin 18 lvc)
> >sometimes is a bit off while its PPS signal is fine.
> 
> Yes, the pps is stated to be accurate to better than a microsecond. The
> interrupt time on your system when quiet is a few microseconds. The NMEA
> response string is maybe good to a few msec at best ( even subtracting out
> the "average" delan due to the length of time it takes to read the string).
> Ie, the fluctuation in the string read time is probably like 10ms, a factor
> of about 10000 worst than the pps. 

allright, understood

> Yes, 185 ms is about how long it takes to read the nmea string (about 70
> characters as 4800 baud is about 1/6 of a second) YOu can tell ntp to
> subtract off say 180ms but that would still leave you with a sizeable
> jitter. 

> >Currently I'm syncing against NMEA/PPS and seeing quiet a big offset:
> For what? This looks exactly like what I would expect.
> 
> >     remote           refid      st t when poll reach   delay   offset  jitter
> >==============================================================================
> >xGPS_NMEA(0)     .GPS.            0 l    7   16  377    0.000  -185.08   1.001  <---
> > PPS(0)          .PPS.            0 l    -   16    0    0.000    0.000   0.001  <---

Now that I got it fully working - linux requires some patching of the
nmea driver -, the offset is gone:

+GPS_NMEA(0)     .GPS.            0 l    8   16  377    0.000    0.003   0.001
oPPS(0)          .PPS.            0 l   14   16  377    0.000    0.002   0.001

> >-muur.intranet.v .DCFa.           1 u    5   64   77    0.072   -9.207   0.023
> >-thegateap.intra .SHM.            1 u   46   64   37    0.873    0.931   0.045
> > SHM(0)          .SHM0.           2 l    -   64    0    0.000    0.000   0.001
> > SHM(1)          .SHM1.           2 l    -   64    0    0.000    0.000   0.001
> > SHM(2)          .SHM2.           2 l    -   64    0    0.000    0.000   0.001
> > SHM(3)          .SHM3.           2 l    -   64    0    0.000    0.000   0.001
> > NTP.MCAST.NET   .MCST.          16 u    -   64    0    0.000    0.000   0.001
> > 192.168.64.0    .BCST.          16 u    -   64    0    0.000    0.000   0.001
> >-auth1.xs4all.nl 194.109.22.19    3 u   48   64   77    7.945    1.514   1.158
> >-auth2.xs4all.nl 193.67.79.202    2 u   46   64   77    9.450   -0.893   0.713
> >+ntp1.nl.uu.net  .GPS.            1 u   45   64   77   13.693    0.173   9.097
> >*chime2.surfnet. .GPS.            1 u  111   64   76   12.262    0.387   1.092
> >-superboer12.stu 193.79.237.14    2 u   45   64   77   13.012    4.401   2.248
> >+ntp.networking4 193.190.230.65   2 u   46   64   77    9.242    0.444   0.494
> >+mailer.zylom.co 193.190.230.65   2 u   44   64   77    9.040    0.430   0.538
> >-aivd.xelerance. 193.0.0.228      2 u   41   64   77    8.881   -0.610   3.154
> What are you doing? Why all of these sources?

The network sources are backup. The 'muur' and 'thegate' hosts are peer
systems in my LAN (with their own radioclocks), MCST/BCST are for
broadcasting/multicasting experiments and SHM0-3 are for my experiments
with shared memory syncing.


Folkert van Heusden

-- 
MultiTail är en flexibel redskap för att fälja logfilar, utför av
commandoer, filtrera, ge färg, sammanfoga, o.s.v. följa.
http://www.vanheusden.com/multitail/
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com



More information about the questions mailing list