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: Greg Wooledge (gregwooledge.org)
Date: Wed Sep 01 2004 - 18:17:40 CDT


Ben Goren (bentrumpetpower.com) wrote:

> I have a laptop. When I woke it from sleep this morning, it was
> -0.387770 sec from the time server on the LAN. That would have been the
> kiss of death for ntp.org. Now? 0.012024 sec. I didn't touch a thing.

I'm running OpenNTPD on both Linux and OpenBSD (with the OpenBSD box
being directly on the Internet, and the Linux box being protected by
it). I've never seen the OpenBSD box have any problems with time sync
so long as I didn't destroy my Internet connection by running a recent
Freenet node. (I.e., as long as I could get response packets back from
my upstream NTP servers in under a second, OpenBSD + OpenNTPD was fine.)

However, there was a brief period of time where the Linux box went
into a death spiral. (Unfortunately, that period of my logs has been
rotated into the bit bucket.) To overshorten a very long story: after
a week or two of running, the Linux clock was about 16 seconds off from
the OpenBSD clock and getting worse. OpenNTPD kept trying to adjust
the clock, and the clock kept not being adjusted. I wrote this off as
either a Linux kernel bug, or an undocumented shortcoming of the
adjtime() Linux system call.

Now let's get some numbers.

On the OpenBSD box, for logs that look like this:

40000000413652b205effb3c reply from 217.127.32.90: offset -0.017475 delay
0.228443, next query 102s

We have the following averages for the negative numbers:

pegasus:/etc/ntpd/log/main$ 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 4620 avg -0.0863758 max -0.000026 min -7.477830

And for the positive numbers:

pegasus:/etc/ntpd/log/main$ 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 3825 avg 0.0791481 max 0.991819 min 0.000000

By the way, those logs contain approximately 3 days' worth of results. (And
yeah, I should've put the logs under /var instead of /etc ... I did better
on the Linux box because that was done second.)

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

Only n=21 samples! This clock doesn't like to be behind. In fact,
I think the negative values need to be discounted in this case, because
they're almost all from the start-up:

griffon:/var/log/ntpd$ tai64nlocal <4000000041319ad223b935d4.s | less
2004-08-28 18:44:35.600757500 ntp engine ready
2004-08-28 18:44:35.600760500 reply from 192.168.2.1: offset -12.764331 delay
0.000371, next query 5s
2004-08-28 18:44:40.502319500 reply from 192.168.2.1: offset -12.761568 delay
0.000262, next query 5s
2004-08-28 18:44:45.509971500 reply from 192.168.2.1: offset -12.758765 delay
0.000259, next query 5s
2004-08-28 18:44:50.517651500 peer 192.168.2.1 now valid
2004-08-28 18:44:50.517653500 reply from 192.168.2.1: offset -12.755974 delay
0.000218, next query 5s
2004-08-28 18:44:55.525389500 reply from 192.168.2.1: offset -12.753169 delay
0.000239, next query 5s
2004-08-28 18:45:00.533124500 reply from 192.168.2.1: offset -12.750359 delay
0.000252, next query 5s
2004-08-28 18:45:05.540885500 reply from 192.168.2.1: offset -12.747567 delay
0.000230, next query 30s
2004-08-28 18:46:05.652807500 ntp engine ready
2004-08-28 18:46:05.652810500 reply from 192.168.2.1: offset 0.004901 delay
0.000265, next query 5s

And now the positive numbers:

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.

griffon:/var/log/ntpd$ cat /etc/ntpd.conf
server 192.168.2.1

That's it.

--
Greg Wooledge | "Truth belongs to everybody."
gregwooledge.org | - The Red Hot Chili Peppers
http://wooledge.org/~greg/ |

P.S.: the hard drive in the Linux box is dying, too. Because of that,
Linux degraded it into PIO mode. That can't help.

[demime 0.98d removed an attachment of type application/pgp-signature which had a name of signature.asc]