system time is off by almost ten minutes but my NTP says it's fine

[Jon Krueger]

System time is almost ten minutes behind, yet ntp is running. Any ideas?


logs
Oct 9 07:29:22 truenas TSC: P-state invariant, performance statistics
Oct 9 07:29:23 truenas 1 2022-10-09T07:29:23.567111-07:00 truenas.local ntpd 10
53 - - ntpd 4.2.8p15-a (1): Starting

ps -aux | grep ntp
ntpd 1054 0.0 0.0 18564 6680 - Ss 9Oct22 2:50.37 /usr/sbin/ntpd -p /var/db/ntp/ntpd.pid -c /etc/ntp.conf -f /var/db/ntp/ntpd.drif


My NTP conf:
server 0.freebsd.pool.ntp.org iburst maxpoll 10 minpoll 6
server 1.freebsd.pool.ntp.org iburst maxpoll 10 minpoll 6
server 2.freebsd.pool.ntp.org iburst maxpoll 10 minpoll 6
restrict default ignore
restrict -6 default ignore
restrict 127.0.0.1
restrict -6 ::1
restrict 127.127.1.0

restrict 0.freebsd.pool.ntp.org nomodify notrap nopeer noquery
restrict 1.freebsd.pool.ntp.org nomodify notrap nopeer noquery
restrict 2.freebsd.pool.ntp.org nomodify notrap nopeer noquery

ntpq -pw

remote refid st t when poll reach delay offset jitter
192.168.1.1 .INIT. 16 u - 1024 0 0.000 +0.000 0.000


ping 0.freebsd.pool.ntp.org
PING 0.freebsd.pool.ntp.org (44.4.53.4): 56 data bytes
64 bytes from 44.4.53.4: icmp_seq=0 ttl=48 time=25.852 ms
64 bytes from 44.4.53.4: icmp_seq=1 ttl=48 time=28.082 ms



Thanks!

-- Jon

 

[winnielinnie]

After having issues with time accuracy and reliability with the default entries, early into using FreeNAS/TrueNAS, I only use one entry in my NTP configuration. (I deleted all the default preset entries for *.freebsd.pool.ntp.org)

I haven't had issues since.

Code:

Address           Burst    IBurst   Prefer    Min. Poll    Max. Poll
us.pool.ntp.org   no       yes      yes       6            10

 

[WN1X]

Your ntpq -pw shows your system is not synced with any NTP server. (Stratum 16 indicates no sync.)

What does ntpq show:

Code:

root@truenas[~]# ntpq 
ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 time.cloudflare .INIT.          16 u    - 1024    0    0.000   +0.000   0.000
*cambria.bitsrc. 132.163.96.1     2 u  718 1024  377   76.869  +12.266   3.028
+12.167.151.1    158.51.134.123   3 u  790 1024  377   16.132  -11.289   2.008
+tick.srs1.ntfo. 206.55.64.77     3 u  319 1024  377   77.262  +22.597   7.904
ntpq>

Above you can see my TrueNAS is not getting any response from "Time.cloudflare.com", but is synced to 12.167.151.1. When I ran service ntpd restart (I am running Core), new servers were picked up:

Code:

root@truenas[~]# ntpq 
ntpq> pe
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 66.85.78.80     172.16.23.153    2 u    7   64    1   48.016   -9.198   0.497
 107-137-68-135. 192.168.1.32     2 u    1   64    1   78.062   -0.983   0.601
 time.nullrouten 132.163.97.1     2 u    1   64    1   72.882   +1.108   0.131
*108.61.73.244   128.59.0.245     2 u    1   64    1   10.215   -0.547   0.103

 

[elvisimprsntr]

1. I configure my pfSense FW to serve NTP time for all clients and add a FW rule to redirect all outbound port 123 traffic to my local NTP server.
2. You might want to consider checking the CMOS battery. New batteries are ~3.3v and fall off a cliff when low. Anything less than ~3.0v you might want to consider replacing.

Code:

[2.6.0-RELEASE][admin@pfSense.redacted.com]/root: ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 us.pool.ntp.org .POOL.          16 p    -   64    0    0.000   +0.000   0.000
-144.172.118.20  154.128.90.233   2 u   68  512  377   36.444   -0.630   0.849
+134.215.114.62  216.239.35.0     2 u  268  512  377   45.366   -0.900   1.238
+23.157.160.168  129.6.15.28      2 u  460  512  377   40.462   +0.198   0.264
*50.205.57.38    .GPS.            1 u   92  512  377   44.116   +0.274   0.126

Code:

root@NAS-1[~]# ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*192.168.69.5    50.205.57.38     2 u   27  128  377    0.220   +0.647   0.105

 

[Jon Krueger]

ntpq> pe 192.168.1.1 .INIT. 16 u - 1024 0 0.000 +0.000 0.000 (service ntpd restart) ntpq> pe *clock.fmt.he.ne .PPS. 1 u 18 64 1 14.232 -6.554 1.816 backoffice-1.in .STEP. 16 u 746 64 0 0.000 +0.000 0.000 +clock.nyc.he.ne 66.220.9.122 2 u 21 64 1 76.081 -9.933 3.772

And now the time is accurate. Hrm. Fixed?

 

[elvisimprsntr]

And now the time is accurate. Hrm. Fixed?

Reach needs to be 377. Takes a few minutes. If it never equals 377, then you still have a problem.

 

[WN1X]

ntpq> pe 192.168.1.1 .INIT. 16 u - 1024 0 0.000 +0.000 0.000 (service ntpd restart) ntpq> pe *clock.fmt.he.ne .PPS. 1 u 18 64 1 14.232 -6.554 1.816 backoffice-1.in .STEP. 16 u 746 64 0 0.000 +0.000 0.000 +clock.nyc.he.ne 66.220.9.122 2 u 21 64 1 76.081 -9.933 3.772

And now the time is accurate. Hrm. Fixed?

Probably fixed...your first NTP peer report shows TrueNAS was trying to use your router (192.168.1.1) as a time source, but it was not responding; because it isn't running an NTP server. After the restart, things look much better.

 

[Jon Krueger]

now:

remote refid st t when poll reach delay offset jitter ============================================================================== *clock.fmt.he.ne .PPS. 1 u 3 64 341 12.902 +106.89 6.707 +backoffice-1.in 206.108.0.133 2 u 58 64 377 67.835 +117.13 2.323 +clock.nyc.he.ne 66.220.9.122 2 u 44 64 377 73.819 +104.03 2.400

So it's working great now. I wonder why it failed before. One possibility: powerfail (thanks PGE), and the NAS came back faster than the router?

 

[elvisimprsntr]

@Jon Krueger Glad it's fixed. Put a UPS on your IT kit.

Those delay, offset, and jitter times are exactly why I serve NTP time from my FW. All clients are using the same local NTP server.