wrong time and date

Do you have time zone and DST set correctly?
I had not at first noticed the date error.  Obviously more than just time zone...
 

On the AREDN network I am using a NTP server running on a raspberry pi,
which uses my home LAMP server as a reference, which uses ubuntu.pool.net.

gelmce@nc8q-mesh-server:~ $ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*www             50.205.57.38     2 u  327 1024  377    4.522   -0.463   3.628

gelmce@nc8q-mesh-server:~ $ ssh www
gelmce@www's password:
Last login: Sun Feb 13 10:43:09 2022 from 192.168.8.99
gelmce@www:~$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 0.ubuntu.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
 1.ubuntu.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
 2.ubuntu.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
 3.ubuntu.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
 ntp.ubuntu.com  .POOL.          16 p    -   64    0    0.000    0.000   0.000
+157.245.125.229 209.51.161.238   2 u  140 1024  377   33.310    0.336   1.556
*50-205-57-38-st .GPS.            1 u  663 1024  377   35.849    1.003   0.995
+t1.time.bf1.yah 98.139.133.62    2 u  361 1024  377   38.975    0.571   1.656
+ntp2.lonet.org  129.134.29.123   2 u  535 1024  377   32.248    0.009   2.397
+chilipepper.can 17.253.34.251    2 u  832 1024  377   96.039    1.069   1.685
gelmce@www:~$

Do any other devices keep time using your 'Meinberg' NTP service?

73, Chuck

 

I've been musing about mesh time, and just decided not to care too much. Someone does have a ntp server up on my local mesh about 4 hops away, I was surprised ntpd could lock onto it; ping time was about 40 msec, jitter was over 30. As long as the jitter is relatively consistent, ntpd can deal with this. Don't expect sub-millisecond accuracy with those stats.

Can the AREDN OS actually run ntpd? All I see on mine is "/usr/sbin/ntpclient -s -l -h <server IP>" which seems to be a hung process started at boot.

Maybe ntpclient is hung because my own ntp server is usually never reachable? Or the call to adjtimex() never returns? I don't have any clients (only Fedora and Raspbian) that have the ntpclient available in a package so I can test this.

So -- maybe check that the ntp server is reachable and locked to a time source before the node is booted?

Also the last time I dealt with this problem, Linux syncs the hardware RTC to UTC, Windows syncs it to local. Make sure your computers are doing it correctly.

I have thought about buying a real time clock or cheapo GPS board for the Pi I keep attached to the local mesh, you can configure chrony or ntpd to use them as a reference. AREDN doesn't need time accurate to the millisecond. 

I have also noticed that my TP Link CPE 510's seem to have a (typically wildly) inaccurate RTC built in. After a power cycle, they come back with a time off by a day or two rather than zero. I would not expect the AREDN software to go through much effort to sync a RTC on every device, given that most nodes are powered down by yanking the power cable.