NTP times jump abruptly
-
Hmm, odd. What happened at that date? Did you upgrade maybe?
Steve
-
Well I have been trying to remember anything specific and I can’t. It’s possible it was an upgrade. The auto backups and config backups don’t go back that far to tell by that either.
-
Check the other monitoring graphs, they should go back that far. You might see a jump in the number or processes or states if it rebooted at that point.
Steve
-
Hmm, nothing with that ype of jump either. I did add another VLAN a few weeks earlier than when the NTP jump happened. Not sure that that would cause this though..
-
Does it remain at those levels if you restart the service? Or restart the firewall? Or set different servers even?
Steve
-
I'm experiementing with that now, will report back.
FYI I am seeing this in the NTP log, not sure if it matters or not:
Mar 20 13:16:12 ntpd 72425 kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized Mar 20 13:16:12 ntpd 72425 kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized -
I see those at boot, they seem normal. I've never dug into those codes though.
Steve
-
Well I change the nist time servers, disabled the VLAN I added back in Jan, restarted the ntpd service. Nothing seemed to make any difference, you can see the pattern over the past 24hrs (Istarted changing stuff at around 12:30 today)
I also see this in the log if it matters:
Mar 20 15:31:26 ntpd 52237 frequency error 500 PPM exceeds tolerance 500 PPM -
Hi @AR15USR
Just a thought - but could this be an indication of a hardware problem with the firewall itself developing? Have a look at this link, especially 3.3.1.1:
http://www.ntp.org/ntpfaq/NTP-s-sw-clocks-quality.htm
Hope this helps.
-
I suppose its a possibility. This is a Atom C2758 board thats been on constantly for several years. Maybe..
-
Ok, if anyone is interested. Just decided to take a look at the graph again, look what recently happened:
-
Hmm, well that looks better. Weird, anything else logged at that point when the offset suddenly came down?
I myself was struggling with an ntp instance that would not ever sync because, it turned out, the system clock was too inaccurate. It's a VM. I eventually managed to get it working as expected by changing the kern.timecounter.hardware value.
Steve
-
That's indeed quite interesting. Did anything change with the system since then (updates, reboots, etc.), or did this correct all on its own sort of randomly?
-
2 things I can recall: First, a package was recently updated, Snort. Second a device on my network had a system upgrade. I'm not quite sure on the timing of the second as it is controlled remotely. I'm tracking down the details on that...
-
Ok was definitely not the device upgrade, that didn’t happen till the 29th..
