OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Re: openntpd and ntpq

From: Henning Brauer (lists-openbsdbsws.de)
Date: Thu Sep 02 2004 - 02:28:14 CDT


* Greg Wooledge <gregwooledge.org> [2004-09-02 08:04]:
> Now, on the Linux side:
>
> griffon:/var/log/ntpd$ grep 'offset -' * 2>/dev/null | awk 'BEGIN {max = -999}
> {n++; t += $6; if ($6 > max) max = $6; if ($6 < min) min = $6;} END {print "n
> " n " avg " t/n " max " max " min " min}'
> n 21 avg -4.29011 max -0.002445 min -12.764331

> griffon:/var/log/ntpd$ grep 'offset [0-9]' * 2>/dev/null | awk 'BEGIN {min =
> 99999} {n++; t += $6; if ($6 > max) max = $6; if ($6 < min) min = $6;} END
> {print "n " n " avg " t/n " max " max " min " min}'
> n 8113 avg 0.390865 max 1.075856 min 0.004901
>
> This is quite representative of what I see whenever I check the logs by
> eyeball. The offset tends to swing wildly in the 0.1 to 0.7 range, and
> occasionally goes over a second.
>
> The Linux machine's performance under OpenNTPD is quite bad, really,
> considering that all it needs to do is sync to the OpenBSD box over a
> 100 Mbps LAN. I don't fully trust it at this point, which is why I keep
> the logfiles open and watch them periodically.

as the logs show, we periodically call adjtime() to, well, adjust for
the offset. and it doesn't get better - we keep calling adjtime() with
offsets in the same range, and it does not seem to do what it is
suppsoed to, adjust the tick frequency slightly to compensate for the
offset. Now, I don't see much of a chance for adjtime() _not_ beeing
the culprit here, it pretty much seems broken on your machine.

--
http://2suck.net/hhwl.html - http://www.bsws.de/
Unix is very simple, but it takes a genius to understand the simplicity.
(Dennis Ritchie)