[ntp:questions] Very large offset and jitter values after reboot
martin.burnicki at meinberg.de
Mon Aug 25 08:26:25 UTC 2008
Nicola Berndt wrote:
>>> remote refid st t when poll reach delay offset
>>> GPS_NMEA(0) .GPS. 0 l 9 64 37 0.000 -580.75
>> 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
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.
More information about the questions