Darrin Chandler wrote:
On Tue, Oct 23, 2007 at 11:49:57AM -0600, Chris Kuethe wrote:
On 10/23/07, Boris Goldberg <[EMAIL PROTECTED]> wrote:
The ntpd from OBSD is raw and lame yet. It takes days (!) to really
synchronize, adjusting time and clock frequency back and forth (even if you
start with -s) so it's too early to say that using it is "right". It will
be "right" after it matures, gets more useful synchronization algorithm and
it's own ntpdate (or a parameter to synchronize and exit).
Blah blah blah.
time1 and time2.srv.ualberta.ca are both running openntpd driven by
nmea(4) sensors. As is my home workstation. They wibble around within
a microsecond or two of the sensor's time, probably due to a)
interrupt handling and b) temperature changes caused by the air
conditioner or cats sleeping on the case.
And my servers are in a windowless room under a lot of concrete and
steel, so there's no good way to get GPS or radio data, and I'm using
other time servers on the internet to sync.
They keep time very well, on sparc64 and amd64, and both are in
pool.ntp.org and score quite well. In fact, they compare favorably to
servers running the more "heavyweight" ntp daemons.
That is a very interesting anecdote. That has got to make Henning proud;
hell I'm proud of him. The amazing thing is that the ntpd binary on my
i386 is only 34.4K. The ntpd binary (non-OpenNTPD) on my i386 FreeBSD
media center is 263K, not to mention all of the other ntp* binaries,
which bring total size to 426K. Plus, OpenNTPD has privilege separation!
