I've talked to several developers about the state of NTP daemons and neither OpenNTPD nor DragonflyBSD's dntpd are suitable replacements. Neither of those support NTP Authentication nor do they have all of the required algorithms required for proper timekeeping.
I'm sure that a good number of people have requirements that OpenNTPD can't satisfy. However, for most home or office users I'm sure it's good enough.
E.g. here's my OpenBSD firewall, which syncs to a number of NTP servers on the net (including pool.ntp.org and time.apple.com):
$ rdate -npv clock.isc.org
Fri Dec 19 18:23:11 PST 2014
rdate: adjust local clock by 0.012466 seconds
And here's an internal OS X desktop running Mountain Lion. It doesn't talk to any NTP servers on the Internet, only to my firewall system running OpenNTPD:
$ ntpdate -qu clock.isc.org
server 149.20.64.28, stratum 1, offset 0.011798, delay 0.05516
19 Dec 18:24:43 ntpdate[2000]: adjust time server 149.20.64.28 offset 0.011798 sec
$ ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*xxxxx.yyyyyyyy. 4.2.2.3 4 u 307 512 377 0.223 5.384 2.611
Being synced to within 12 milliseconds of a reliable stratum 1 NTP server is good enough for me. NB: I don't normally use clock.isc.org, there are plenty of stratum 2 and higher servers available for use.
Hey, if ultra-precision time is an issue,
go buy an atomic clock, I'm sure if your needs
are that precise, you can probably afford it.
openntpd is intended to be SMALL, SIMPLE and SECURE.
Not HUGE, COMPLEX and "Hope for the Best".
>nor do they have all of the required algorithms required for proper timekeeping.
I hear something like that a lot, yet all my systems run openntpd and all of them are keeping proper time without issue. What exactly is so not proper about it, and which algorithm exactly does it need to be "proper"?
People who are into timekeeping are like, really, really into timekeeping. I've been skating by with improper timekeeping, too (whatever that means), but I only need to correlate web log entries and not hadron collisions.
I do not know if this is an issue with other ntp daemons today, but I've been bitten by some of them in the distant past - they might keep the time fine, but it really sucks if they sometimes jump the clock instead of properly slewing it.
Having to try to debug intricate problems and not knowing if you can trust timestamps on the logs for the actual order of events can drive you nuts.
There's a big difference between "proper" and "more accurate than 99.999999999% of people care about" though. How many microseconds of accuracy do most people need? How many does openntpd provide and how many does the other ntpd provide? Claiming it isn't "proper" because in theory it may be 2 microseconds less accurate in some circumstances sounds like FUD.
