On Mon, 21 Mar 2005 09:46:34 -0500, Matthew Miller <mattdm@xxxxxxxxxx> wrote: > I think there's been some discussion before. I'm basically for it, although > we wouldn't want to jump ship on the existing, working program without some > good testing. Perhaps the best approach interim approach is to configure the > existing ntp with the 'alternatives' system a la sendmail/postfix/exim, and > then add openntpd to extras? A move to openntpd without careful consideration would be a major mistake. OpenNTP has the advantage of simplicity, but it lacks much of the algorithmic sophistication in the official NTPv4. For example, the huff/puff filter which does a great job of improving NTP performance for hosts on tight pipes. This will translate into worse time keeping, increased levels of ntp related network traffic, and worse handling of network outages. (more accurate clocks need less frequent updates, on most systems once locked ntpd is pretty good at keeping subsecond alignment even if the network is gone for a long chunk of time) If we are willing to throw away the algorithmic sophistication of ntpd, then we should strongly consider just implementing a SNTP client. A sntp client would meet the basic clock setting needs of most users, and would be even simpler than the openntp client. It would also avoid misleading users by failing to provide the level of algorithmic sophistication expected from ntpd. I wasn't aware of NTP being a substantial security worry, I think there is still a lot of mileage to be had with the existing app before complete replacement is needed.
