[ntp:questions] ATOM falseticker with flag3 enabled

[A C]

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.