That was the hint I needed! The main router the RasPi is connected to
also runs chrony and acts as the timeserver for all local network
clients. However, the script managing that chrony instance had an option
to redirect all NTP traffic through the router. Interesting that I did
not find that rule in the router config. This is the RasPi after
toggling that option off:
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
#- GPS 0 4 377 9 -45ms[ -45ms] +/-
100ms
#* PPS 0 4 377 8 -461ns[ -537ns] +/-
648ns
^? zeit.fu-berlin.de 1 8 377 66 -4025us[-4025us] +/-
58ms
^? ptbtime1.ptb.de 1 8 377 71 -3100us[-3100us] +/-
9719us
^? ptbtime2.ptb.de 1 8 377 72 -2490us[-2490us] +/-
8901us
^? ptbtime3.ptb.de 1 8 377 73 -4077us[-4077us] +/-
9630us
^? ns.tu-berlin.de 2 8 377 69 -3061us[-3062us] +/-
16ms
And maybe this also solves the issue that the router (using the RasPi as
sole source) was never able to correct an offset of -200ms. If not, I
will come back soon.
Thanks again for your help!
Miroslav Lichvar schrieb am 05.06.23 um 10:02:
On Sun, Jun 04, 2023 at 12:07:44PM +0200, Torsten Wolf wrote:
Not sure why the Reach value for the PPS source is 113. A few minuts later
that value increased to 372, just to go down again afterwards.
That might be due to changing offset between GPS and PPS. Try
adjusting the offset option to make it closer to the middle as
explained in the FAQ.
Local address : 192.168.1.105 (C0A80169)
Leap status : Normal
Version : 4
Mode : Server
Stratum : 2
Poll interval : 7 (128 seconds)
Precision : -25 (0.000000030 seconds)
Root delay : 0.000778 seconds
Root dispersion : 0.269699 seconds
Reference ID : C0A80169 ()
Reference time : Sun Jun 04 10:00:57 2023
Offset : -0.142506495 seconds
Peer delay : 0.000236495 seconds
Peer dispersion : 0.000000898 seconds
Response time : 0.000178912 seconds
Jitter asymmetry: +0.00
NTP tests : 111 111 1110
The test D is failing. That's the loop detection. The Reference ID is
the same as the local address, i.e. the client is polling a server
which seems to be synchronized to the client. As this happens with all
NTP servers and the peer delay is very short, I think it might be a
firewall in local network redirecting NTP requests to itself.
