2011/12/29 Nickolay Orekhov <nowh...@mail.ru>
> Yes, you are right. Your system is synced with PPS and gets seconds from > NMEA. > You can set time1 to make NMEA offset closer to reality ( and to PPS ). > > By the way, if you have only two clock sources, NMEA + PPS and offset > between them is bigger then "mindist" they > will be marked as falsetickers and there'll be no sync. > You might want to increase it by specifying: "tos mindist _value_" in your > ntp.conf. > > Default mindist is 0.001s, so as a wild guess, I can suppose that you set > your clock to "true" or already increased mindist or > you have another one source, NTP maybe, otherwise they will be > falsetickers. > > 2011/12/29 Tomi Lehto <tle...@iki.fi> > >> Hello, >> >> >> I have ntpd set up with two time sources, GPS_NMEA and a PPS pulse, and I >> have a couple >> of perhaps basic questions. >> >> NMEA sentences are not read directly from a physical serial port but a >> "virtual" >> /dev/gps0 that is fed by a separate process. >> PPS pulse comes from the gps module and is handled by custom Linux kernel >> driver. >> >> With no time1 fudge values set for either of the drivers, I let the >> system run >> over night and it settled so that 'ntpq -p' shows >> >> remote refid st t when poll reach delay offset >> jitter >> >> ============================================================================== >> *GPS_NMEA(0) .GPS. 10 l 53 64 377 0.000 335.809 >> 20.427 >> oPPS(0) .PPS. 0 l 6 16 377 0.000 0.005 >> 0.004 >> remote refid st t when poll reach delay offset >> jitter >> >> ============================================================================== >> *GPS_NMEA(0) .GPS. 10 l 9 64 377 0.000 331.531 >> 16.355 >> oPPS(0) .PPS. 0 l 10 16 377 0.000 0.005 >> 0.004 >> remote refid st t when poll reach delay offset >> jitter >> >> ============================================================================== >> *GPS_NMEA(0) .GPS. 10 l 29 64 377 0.000 331.531 >> 16.355 >> oPPS(0) .PPS. 0 l 14 16 377 0.000 0.003 >> 0.00 >> >> running 'ppstest /dev/pps0' shows >> >> source 0 - assert 1325148282.999996125, sequence: 985573 - clear >> 0.000000000, sequence: 0 >> source 0 - assert 1325148283.999996770, sequence: 985580 - clear >> 0.000000000, sequence: 0 >> source 0 - assert 1325148284.999995073, sequence: 985587 - clear >> 0.000000000, sequence: 0 >> source 0 - assert 1325148285.999996346, sequence: 985594 - clear >> 0.000000000, sequence: 0 >> source 0 - assert 1325148286.999995188, sequence: 985601 - clear >> 0.000000000, sequence: 0 >> >> >> Does that assert time of +/- ~5 usec within a second change tell that the >> system >> clock is running in sync (and in the same phase) with the pps pulse, or >> do I >> understand that completely wrong? >> >> Other thing is the GPS_NMEA offset in ntpq output; looking at the output >> from last >> night it varies between 300 and 350 ms. Does that matter, since the pps >> pulse >> tells when the second starts so having the time from the gps within the >> correct >> second should be enough, no? Or should I tweak fudge time1 value for the >> NMEA >> driver to 350 or so to get is near zero? (NMEA jitter stays under 20 ms >> most of >> the time, some larger peaks every now and then.) >> >> Thanks much, >> Tomi >> >> _______________________________________________ >> questions mailing list >> questions@lists.ntp.org >> http://lists.ntp.org/listinfo/questions >> >> > _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
