On 10/23/07, Boris Goldberg  wrote:

quoted text
>   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?