On 2012-03-03 at 12:24 +0100, Henning Brauer wrote: > * Phil Pennock <openbsd-misc-p...@spodhuis.org> [2012-03-02 16:32]: > > A brief skim of the source (4.6p1) suggests that OpenNTPd passes on > > well, 4.6 is ancient. unfortunately nobody maintains the portable atm. > > that said, otoh there we no changes regarding leap seconds afterwards.
Noted; I'd also checked the cvsweb source and didn't see anything. I've created a git repo and shoved it to github (since it's free and more reliable than any single box I have available to throw at this, and someone else is paid to maintain security updates). https://github.com/syscomet/openntpd The current CVS of ntpd was imported to the initial branch "openbsd" and I branched "master" from that. I then pulled in the imsg stuff from current OpenBSD and then went through the FreeBSD Ports packages, applying the changes which seemed sane (almost all of them). Only *incompatibility* with upstream is storing drift information as parts per million, for compatibility with reference ntpd. I made the routing table support conditional upon a compat.h #define which currently defaults undef, because my dev box is in need of a major OS upgrade and I don't have multiple routing table support on my FreeBSD box. Seems to work for me. Is a starting point for being able to hack other stuff in. I only care about leap-seconds. I'm thinking leap-second support should come in two modes: * Pause system time for one second, per reference ntpd. * Smear time, for a little while before and after the leap-second, so that adjtime takes care of it; I know at least one large install does this, to avoid major issues I do not see any need to support: * Standards compliant, non-monotonic time, repeat a second For smearing, since adjtime stuff is a 10% variance and we need to handle 1 second, 10 seconds at max frequency skew should do it. Double that, so we're not at max and can account for pre-existing need for adjustment, and that's a 20 second window centered on the leap-second. To deal with all the brokenness detailed at: http://members.iinet.net.au/~nathanael/ntpd/leap-second.html I'm pondering options. I suspect that for one day before the cut-over, if a server appears to be a second off in the direction indicated by the leapsecond, and the server hasn't set the leap flag, then auto-add/subtract the implicit second to/from its time, to get the effective time for calculations. *After* the cut-over is more awkward, as the leap flag is cleared after the leap-second, so we can't implicitly tell if the server never knew of the leap-second and is wrong, or if the server has adjusted but its time is legitimately different. I'm thinking of in-memory state to track if we did see the leap-second from that server, and keep it for two days, and lose the state if someone restarts ntpd, so that we then need to rely upon normal voting rules. Informed feedback very welcome. For now, I'm going to be a slacker and go to bed. -Phil
