Nicola Berndt wrote: >>> remote refid st t when poll reach delay offset >>> jitter >>> ============================================================================== >>> GPS_NMEA(0) .GPS. 0 l 9 64 37 0.000 -580.75 >>> 3965.19 >> >> You've not had your first 8 samples yet. You haven't actually had >> enough for ntpd to act on the data. You can speed that up with iburst, >> but ntpd will still take a long time to get a very tight lock. jitter >> will reduce as you get to the eight samples. The good? think, is that >> you are more than 128ms out, so that ntpd will step the time, to zero >> the offset, once it gets enough samples. > > > Just tried the iburst option, but I had to figure it only works with the > server command, not on refclocks. > > What really puzzles me, is the stoical 600 ms offset after rebooting. > Since it is always returning having more or less the same amount, I > should really be able to get rid of it, no?
Maybe you should first try to find out whether the initial system clock is off by 600 ms after reboot, in which case the problem is due to the mainboard's RTC, or whether the first NMEA string(s) after power-up are sent with that time offset Run ntpq -c as to get the list of associaton IDs from your running NTP daemon, and then run ntpq -c "rv assid" where you replace assid by the association ID listed by the first command. This displays ntpd's filter values. If do this after the first few samples the the output should show whether all NMEA strings show the 600 ms offset, or only the first (few) entries. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
