frequency tolerance: 500

[Udo van den Heuvel]

On 31-03-19 12:34, Achim Gratz via devel wrote:
>> This behaviour is not normal.
> 
> Uh, that is reporting from an ntpd that has just started and hasn't

One that starts counting again after being up for a little while.

> collected many statistics.  So the only way it can get a PLL frequency
> of 186ppm will be if that value is stored in the drift file.  Do you
> have one (usually found somewhere in /var/lib/ntp/), does it contain a
> sensible value?

186 is not sensible.
When I set it to 0.000 it still goes way up.

>> is it software?
>>
>> rebooted again to 4.19.23 which shows different behaviour than 4.19.30
>> and 32.
> 
> What are these version numbers, Linux kernel?  

Of course.

> If so, this doesn't seem
> to be a rasPi, what is it?  

No, x86_64 with AMD Ryzen.

> Also, just mumbling about "different
> behaviour" without showing at least one difference isn#t really going to
> get you much help.

We either get a pps that is ~250ms off (4.19.30 etc) with ntpd going
backa nd forth between the gps and remote clocks.
Or we get this absurd PLL frequency. (4.19.23).

Of course this might just be timing, depending on how soon after bootup,
at what spot in the PPS cycle ntpd came online.
But I am not yet convinced of that.
Restarting leads to same results.

Udo