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. If you have some reasonable, well-designed suggestions on how to better discipline the clock, we're all ears. Other wise, quit babbling - openntpd is doing exactly what it's supposed to: be a simple, lightweight daemon for keeping your clocks "close enough". If that's not good enough for you, the ntp.org daemon is in ports. CK -- GDB has a 'break' feature; why doesn't it have 'fix' too?
