3 ms·

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 suppo

by feld 12y ago

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.

imanaccount247 12y ago
>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"?
- tedunangst 12y ago
  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.
- wglb 12y ago
  From the openntpd.org site at http://www.openntpd.org/goals.html http://www.openntpd.org/goals.html: Reach a reasonable accuracy. We are not after the last microseconds. Whereas NTP looks for maximum accuracy.
  - imanaccount247 12y ago
    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.
- noselasd 12y ago
  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.
PhantomGremlin 12y ago
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.
moe 12y ago
Here is the corresponding debate between the ntp guys and the OpenBSD guys (from 2004): http://www.monkey.org/openbsd/archive/misc/0408/msg00562.html http://www.monkey.org/openbsd/archive/misc/0408/msg00562.htm... The TLDR from the OpenBSD side of things: 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".
feld 12y ago
late edit: Might make sense to say "precise" instead of "proper"

by feld 12y ago

imanaccount247 12y ago

>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"?

tedunangst 12y ago
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.
wglb 12y ago
From the openntpd.org site at http://www.openntpd.org/goals.html http://www.openntpd.org/goals.html: Reach a reasonable accuracy. We are not after the last microseconds. Whereas NTP looks for maximum accuracy.
- imanaccount247 12y ago
  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.
noselasd 12y ago
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.

PhantomGremlin 12y ago

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.

moe 12y ago

Here is the corresponding debate between the ntp guys and the OpenBSD guys (from 2004): http://www.monkey.org/openbsd/archive/misc/0408/msg00562.html http://www.monkey.org/openbsd/archive/misc/0408/msg00562.htm... The TLDR from the OpenBSD side of things: 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".

feld 12y ago

late edit: Might make sense to say "precise" instead of "proper"