You have not left it running long enough. You need to wait until the reach is 377, then it should start to settle. The tools with the ntpd package do not show the unit, so you cannot tell what the numbers mean. Grabbing ntpq from ntpsec and passing the -u switch will give you them.
You also need to give the details from the ntpd server itself and whether it is trully running kernel PPS.
For my system contacting an RPi4 over 802.11ac, I see:
remote refid st t when poll reach delay offset jitter
===============================================================================
*feeder.docile.b .PPS. 1 u 8 32 377 3.424ms -3.613ms 3.300ms
*feeder.docile.b .PPS. 1 u 8 32 377 3.424 -3.613 3.300
I have tried over ethernet as well. Also, all other nodes sync with the same RPI getting the time from GPS/PPS and they don’t show this big of a drift.
How long is long enough? It still show reach of 1 and seems like is not even syncing with it anymore. This has been a constant issue with the bpi-r3 for me. I don’t think it’s a matter of not waiting long enough.
root@bpi-r3:~# ntpq -p
remote refid st t when poll reach delay offset jitter
=======================================================================================================
16.14.168.192.wifi 200.89.75.198 3 u 38 64 1 1.2141 96.3744 58.1250
root@bpi-r3:~#
root@bpi-r3:~# uptime
15:05:45 up 18:40, 2 users, load average: 0.58, 0.28, 0.21
Reach goes through 1, 3, 7, 17, 37, 77, 177, 377 and 377 is the key. Poll is the number of seconds between contact (actually + 2 or 3 more). The reset is because the ntpd on the BPi is not contacting the remote ntp server. I think this is due to a bug in the software. I had this problem back in April, but it seems stable now running 4.2.8p15-4.
You may want to post your ntp.conf file void of any comments or sensitive info.
No improvement after more than 1 day of uptime. As you can see. the drift floats from 90 to 400ms. It seems like an issue with the BPI-R3. I’m not an expert, I’m not sure what controls the clock behavior.
Would anything improve by adding an external RTC? Thanks!
root@bpi-r3:~# ntpq -p
remote refid st t when poll reach delay offset jitter
=======================================================================================================
16.14.168.192.wifi 200.89.75.198 3 u 23 64 1 1.3164 195.6712 0.0000
root@bpi-r3:~#
root@bpi-r3:~# uptime
13:14:43 up 1 day, 16:48, 1 user, load average: 0.05, 0.15, 0.22
I had the same issue with plain ntpd. I put it down to having the channel analysis window open on the BPi. Which if you think about it, really messes the wi-fi up since it scans the frequency range thus spoiling any current connections.