[ntp:questions] ATOM falseticker with flag3 enabled
agcarver+ntp at acarver.net
Mon Apr 2 01:22:29 UTC 2012
On 3/31/2012 20:19, David Lord wrote:
> A C wrote:
>>> I'm not sure which value you are referring to. From the
>>> "ntpq -p" billboard over a day, I see values of jitter
>>> of the GPS as low as 0.002
>> Yes, it's that jitter however there's a minimum computed value below
>> which it never goes (varies per system). On my system it used to be
>> computed at 0.061 (and all the configured clocks would report that as
>> an initial jitter until some data came in). On the same system with
>> 4.2.7 the value is now computed to be 0.122.
>> In any case apparently according to David Hart the code has indeed
>> changed so the computations are different.
> Even after warm restarts I don't concern myself with the
> level of jitter until ntpd has had time to stabilise. After
> an update to ntpd or kernel, and without a pps source, it
> can be a day or more until a stable value for drift has
> been established.
> Has using 4.2.7 solved the problem with the type 20 and 22
> drivers both being marked as falsetickers?
> Were you able to determine a reasonable fudge time value
> for the type 20 driver by using noselect for the type 20
> driver and having several good internet sources?
Here's one to break everyone's brain:
Using flag3 on ATOM with no prefer peer still disciplines the clock via
the PPS signal but marks ATOM as a falseticker. Setting a prefer peer
causes ATOM to be marked as a good clock ('o' tally code).
The kicker: the clock runs better with the first configuration (no
prefer peer but still disciplined) than with the second configuration.
The offset on my system stays around +/- 5 us normally (unless the
furnace turns on) when ATOM is marked a false ticker. But when it's
configured with the prefer peer, it hovers around +/- 30 us.
I'd rather have the better clock AND not be marked as a false ticker.
More information about the questions