OpenNTPD 5.7p1 Released | Hacker News Reader

OpenNTPD 5.7p1 Released

undeadly.org

65 pointsprotomyth11 comments

As a reminder, and alternate and clean-slate implementation of NTP started by phkamp, Ntimed [1], was featured on HN a few days ago [2]

[1] https://github.com/bsdphk/Ntimed [2] https://news.ycombinator.com/item?id=8781435

Don't forget standards-compliant.

I use the native OpenNTPD on OpenBSD and it works like a charm. No DDoS or buffer overflows, but it keeps me regular.

Theo recently posted to the OpenBSD tech list stating that ntp.org has 66x the lines of code of OpenBSD's OpenNTPD:

http://marc.info/?l=openbsd-tech&m=141905854411370

A good portion of the size difference (though certainly not all) is that ntp.org's ntpd has a lot of drivers to interface with physical devices [1], while OpenNTPD doesn't. If you don't own the physical devices, the LoC in the drivers are kind of a wash: they're not useful to you, but you also won't be running them. A stripped-down NTP-client-only build option would be nicer, though. PHK's suite of ntpd replacement tools seems to be going in that direction, offering a client-only tool for edge servers that just need to sync time over the network.

[1] http://www.eecis.udel.edu/~mills/ntp/html/refclock.html

On OpenBSD the integration with physical devices is done via builtin software. I run a stratum 1 OpenNTPD server on OpenBSD, with a GPS attached via nmea [1]. The GPS data shows up via the sensors framework, which OpenNTPD interfaces with [2].

[1] http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man4/...

[2] http://openbsd.id/papers/radio-clocks-asiabsdcon07.pdf

It's interesting how the author of the paper (and work) gets PPS sampling wrong.

Another difference is that OpenNTPD appears to only implement the less accurate SNTP subset of NTP.

Exactly. I was never meant to totally replace NTP but to cover only the most common usage of it.

Note that according to the RFCs, one can be a SNTP sender (master) or receiver, but not both.

This is why OpenNTP is not RFc compliant.

Check out the new features page as well. It has some interesting and unique capabilities that I didn't know about before I started the porting work.

http://openntpd.org/features.html

OSX really needs adjtimex or ntp_adjtime for high-precision clock synchronization for PLL loops (unless there's another way). If XNU devs wont do it, I may consider adding a new call to the sysent table via a kext (easier to do because of advances in modern open source rootkits). There's a partial port from a BSD to XNU for a starting point. XNU devs ignored that patch author entirely the first time. It's really a shame when collaboration for useful improvements are turned down.

Reply on news.ycombinator.com