[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: openntpd and ntpq



Hey all...

Just in case it's useful, here's my real-world experience with ntp.  I'm
not a professional C developer, so I'm sure I'll miss some of the
subtleties of this thread (I'm a professional web developer (hey! stop
laughing.  I've done some significant stuff -- I built an entire telco
from the ground up)).

I had all kinds of problems with ntp-4.1.74 on OpenBSD 3.4 on one
particular server ("GenuineIntel" 686-class).  The daemon exhibited the
"pinball machine" syndrome and would eventually crash.  I was told that
I had bad hardware.  I upgraded to OpenBSD 3.5 and almost all of the
problems went away, although ntpd would still sometimes lose sync.

(nit-picking point -- "lose" is the opposite of "gain".  "loose" is the
opposite of "tight". ;-)

I tried djb's clockspeed with no success (I won't pursue this issue any
further, as I understand djb can raise hackles, and I'm otherwise a fan
of his stuff).

Recently (late July), I came across OpenNTPD, and installed it on one of
my servers, the one that had spat out ntp-4.1.74.  I found that it would
make a small adjustment to the clock every 4 minutes.  And I mean EVERY
4 minutes, usually on the order of .1 seconds.  I upgraded to the
20040824 distribution, and now after about 3 days of running it, about
once an hour, sometimes less, I see an adjustment to the clock of about
.05 seconds.  And it's improving steadily.  If this is indeed an erratic
hardware clock, I'm impressed by OpenNTPD's ability to control it where
everything else failed.

(Btw, can we take the macho stud posturing bullshit outside, please?  In
an environment where newbies are exhorted -- sometimes violently -- to
RTFM, how does it look when they do search the archives and all they
find is this nonsense?)

Peace out, y'all.  You're doing good work.  And I mean 'good' in a VERY
significant sense.

Cheers,
Alex