Hacker News Reader

Comment by hiphopyo | Hacker News Reader

Might want to check out OpenBSD's OpenNTPD:

http://www.openntpd.org/

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.

>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.

From the openntpd.org site at http://www.openntpd.org/goals.html:

Reach a reasonable accuracy. We are not after the last microseconds.

Whereas NTP looks for maximum accuracy.

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.

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.

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.

Here is the corresponding debate between the ntp guys and the OpenBSD guys (from 2004):

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

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

The portable version (for Linux and other OSes) is unmaintained and the last release is from 2006. I don't use it on that basis alone.

Also, the last release of non-portable openntpd is from 2009.

There's little point to a non-portable release. They were made when ntpd was developing faster than OpenBSD, but it's not like OpenBSD stopped making releases in 2009.

There is also systemd-timesyncd and Chrony.

Fedora (or GNOME 3?) uses Chrony by default due to better power management. I assume the same is true for most other distributions.

systemd-timesyncd implements SNTP, which is not the same.

systemd-timesyncd is not much of an alternative. It is simply an sntp client, it does not serve time to other hosts nor can it use reference clocks.

Sure, but IMO enough many systems use NTP only in a sntp manner to mention it.

SNTP is only useful as an option of last resort, e.g. you have no embedded RTC, and no storage to track drift. In all other cases a full NTP client is always preferable, since drift and corrections can be applied without causing jumps to the system clock (triggering software bugs and misfired events), and drift statistics can be recorded -- which is inevitably required in almost all circumstances where you're using even high end PC motherboards that still rely on a $.15 crystal time reference

SNTP is close to useless. Your time server could be off and you'd happily follow along.

Reply on news.ycombinator.com