Darrin Chandler wrote:

quoted text
> On Tue, Oct 23, 2007 at 11:49:57AM -0600, Chris Kuethe wrote:

>

>> On 10/23/07, Boris Goldberg  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!