OpenNTPD works well few days and then not sync
-
As an extra data point, this is definitely an OpenNTPD issue as it's even happening on 2.0.2 images I'm building and testing. My ALIX has been up ~16hrs and is logging that its clock is being reset by around -1400000 seconds.
We're discussing dropping OpenNTPD in favor of FreeBSD's even though we've hesitated in the past. We'll have to work around its limitations in other ways, but it's better than having a wonky clock.
-
"We're discussing dropping OpenNTPD"
Sweet!!! No more having to edit the ntp.conf every update to pfsense and manually start ntpd.
-
Current snaps should be switched to ntpd, works fine for me so far on a vm.
Some notes that I mentioned to other devs about the switch:
1. The boot-time behavior needs some observation, not sure if what I'm doing there is sufficient. I pass -g to ntpd which allows a large first skew, but I'm not sure if it's fast enough to sync at boot. We may need to bring back the call to ntpdate in rc before launching.
2. FreeBSD's ntpd has no concept of selective binding/listening, it listens on all by default, and we can't use its restrict keywords because they are not compatible with *.pool.ntp.org - the restrict keywords can't handle multiple A records being returned. As such, I removed Services > OpenNTPD since the options were now irrelevant.
3. I added a status page at Status > NTP that parses the ntpq output
Adding on 3, I committed a fix today to clean the page up and make it a little better, but that's not in a snapshot yet.
-
That may be possible. If you pkg_add -r that and it works with those keywords, it would certainly be worth adding in.
FYI- checked in a bunch more fixes this afternoon for various issues I found, it's fairly solid now.
If we can get the interface bindings to go that'll be the icing on the cake.
As an added bonus, this ntpd support ipv6, openntpd did not.
-
Just a little html error need to be corrected in status_ntpd.php :
Tally code
Server
Ref ID
Stratum
Type
When
Poll
Reach
Delay
Offset
Jittershould be :
Tally code
Server
Ref ID
Stratum
Type
When
Poll
Reach
Delay
Offset
JitterBTW, ntpd works well and stay synchronized since one hour. I will check for the long term. Thanks !!!
-
That's already been corrected.
-
A question about a somewhat related topic: When there is a large time skew, is it possible to sync time without rebooting pfsense (which invokes ntpdate on startup) ?
I run pfsense in a VM and suspend/hibernate the host PC every evening, which results in several hours time diff when the PC wakes up the next morning. Unfortunately in this scenario ntpd won't sync to the correct time, even after pfsense has been running for several hours.
I could create a cron job to periodically run ntpdate -s xyz, but maybe pfsense offers a better way which I haven't found yet.
-
On new snaps (not out yet) or 2.0.2 you can run /usr/local/sbin/ntpdate_sync_once.sh
That will kill ntpd, run ntpdate to force a sync, then restart ntpd.I suppose I could add a button to Status > NTP to invoke that.
-
On latest Snap, nano i386, D510MO. Would not stay synced without use of JimP script.
Changed /var/etc/ntpd.conf.
On server lines, removed iburst, set minpoll 6 maxpoll 6.Staying within 1 ms for 12 hours now.
-
The values after the server line were pulled from FreeBSD's defaults. Not sure why yours needed to be changed that much.
What was the clock doing when you said it wouldn't stay in sync?
We may need to have a settings page to tweak those values if the defaults don't work for everyone.
-
maxpoll 6 is pretty aggressive.. This is talking to ntp server every 64 seconds.. This really should not be required, normally maxpoll will work its way up to 9, or 1024 seconds.
Normally you should not have to make changes to these settings.
-
OK, locking this topic for now so it doesn't attract more random ntp issues, this thread originally was for OpenNTP losing sync which is very far away from tweaking ntpd.
I may split some older posts from this topic off into separate threads since there are still interesting things in them, but they have diverged from the original topic.
