frequency tolerance: 500

[Udo van den Heuvel]

On 31-03-19 11:21, Achim Gratz via devel wrote:
> Udo van den Heuvel via devel writes:
>>> How close are you to "true" time when you start the ntpd?
>>
>> Within 100's of ms if not better.
> 
> If you are really that far off when you start ntpd, 

When simply rebooting?

#  ntpq -c kerninfo -pn
associd=0 status=0028 leap_none, sync_unspec, 2 events, no_sys_peer,
pll offset:            25.623
pll frequency:         186.259
maximum error:         0.10146
estimated error:       0.00972
kernel status:         pll nano
pll time constant:     6
precision:             1e-06
frequency tolerance:   500
pps frequency:         0
pps stability:         0
pps jitter:            0
calibration interval   0
calibration cycles:    0
jitter exceeded:       0
stability exceeded:    0
calibration errors:    0
     remote                                   refid      st t when poll
reach   delay   offset   jitter
=======================================================================================================
xNMEA(0)                                 .GPS.            0 l    -   64
   1   0.0000  48.1256   0.0000
x192.168.10.98                           .GPS.            1 u   35   64
   3   0.2999  27.4933   4.5941
 fd00:c0a8:a00:1::1                      .GPS.            1 u    7   64
   1   0.3935  55.0019   0.0000
 2001:888:0:7::2                         193.67.79.202    2 u    5   64
   1  14.9598  60.2632   0.0000
 2001:888:0:7::22                        193.67.79.202    2 u   60   64
   1  15.5002  23.9193   0.0000
 193.67.79.202                           .STEP.          16 u    -  128
   0   0.0000   0.0000   0.0002
 193.79.237.14                           .STEP.          16 u    -  128
   0   0.0000   0.0000   0.0002
 185.31.230.94                           .STEP.          16 u    -  128
   0   0.0000   0.0000   0.0002
 134.221.205.12                          .STEP.          16 u    -  128
   0   0.0000   0.0000   0.0002


This behaviour is not normal.
is it software?

rebooted again to 4.19.23 which shows different behaviour than 4.19.30
and 32.

Udo