> >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 _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
