From owner-freebsd-security Sun Aug 22 4:44:20 1999 Delivered-To: freebsd-security@freebsd.org Received: from maxim.gba.oz.au (gba.tmx.com.au [203.9.155.249]) by hub.freebsd.org (Postfix) with SMTP id E3AC015553 for ; Sun, 22 Aug 1999 04:43:51 -0700 (PDT) (envelope-from gjb-freebsd@gba.oz.au) Received: (qmail 23604 invoked from network); 22 Aug 1999 21:41:16 +1000 Received: from alice.gba.oz.au (192.168.1.11) by maxim.gba.oz.au with SMTP; 22 Aug 1999 21:41:16 +1000 Received: (qmail 6731 invoked by uid 1001); 22 Aug 1999 21:41:15 +1000 Message-ID: <19990822114115.6730.qmail@alice.gba.oz.au> X-Posted-By: GBA-Post 1.03 20-Sep-1998 X-PGP-Fingerprint: 5A91 6942 8CEA 9DAB B95B C249 1CE1 493B 2B5A CE30 Date: Sun, 22 Aug 1999 21:41:14 +1000 From: Greg Black To: Ben Smithurst Cc: freebsd-security@FreeBSD.ORG Subject: Re: Securelevel 3 ant setting time References: <19990820214657.1605.qmail@alice.gba.oz.au> <19990821171004.A24337@lithium.scientia.demon.co.uk> In-reply-to: <19990821171004.A24337@lithium.scientia.demon.co.uk> of Sat, 21 Aug 1999 17:10:04 +0100 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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 -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message