Date: Sun, 22 Aug 1999 21:41:14 +1000 From: Greg Black <gjb-freebsd@gba.oz.au> To: Ben Smithurst <ben@scientia.demon.co.uk> Cc: freebsd-security@FreeBSD.ORG Subject: Re: Securelevel 3 ant setting time Message-ID: <19990822114115.6730.qmail@alice.gba.oz.au> In-Reply-To: <19990821171004.A24337@lithium.scientia.demon.co.uk> of Sat, 21 Aug 1999 17:10:04 %2B0100 References: <XFMail.990820115204.andrews@TECHNOLOGIST.COM> <19990820214657.1605.qmail@alice.gba.oz.au> <19990821171004.A24337@lithium.scientia.demon.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Ben Smithurst writes:
> > If you happen to have a machine that needs its regular tweaks by
> > ntpdate to exceed half a second, then you can adjust the kernel
> > tick a few units either side of its default setting of 10000 so
> > that things stay relatively stable.
>
> Where should I change this? I tried changing the value in
> /sys/conf/param.c (after copying it to the compile directory) and
> it seems to have had no effect. I changed it to 9997, I calculated
> this as the best value given that my machine's clock seems to gain
> about 1 second per hour. The clock still seems to be running fast,
> according to the adjustments made by ntpdate. The new value shows up in
> kern.clockrate so I must have got something right.
>
> root@scientia:/sys/compile/SCIENTIA# sysctl kern.clockrate
> kern.clockrate: { hz = 100, tick = 9997, tickadj = 5, profhz = 1024, stathz = 128 }
The way I would do this is to stop ntpdate (and any other time
adjusting things) from operating while I was playing with the
tick value. Then just run the machine for 24 hours and see how
far it drifts. Make an adjustment to tick and go for another 24
hours. Keep going until it stays within half a second of the
right time. Then go back to regular corrections with ntpdate
and all will be well.
I haven't ever done this on a FreeBSD machine. The only machine
that I use as a time server that needed tweaking was an old 486
running BSD/OS. BSDI provide a tickadj program with the ntp
tools which can adjust the tick value on a running kernel, and I
have a call to it in the /etc/rc on that machine. But it seems
to tweak the same thing as you have found. Here's its sysctl
output:
kern.clockrate: hz = 100, tick = 9997, profhz = 100, stathz = 100
That machine only gets to run ntpdate once a day and it rarely
requires an adjustment of greater than 300 ms and never greater
than 500 ms.
--
Greg Black -- <gjb@acm.org>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990822114115.6730.qmail>