From owner-freebsd-current  Thu Dec 28 03:30:08 1995
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id DAA28851
          for current-outgoing; Thu, 28 Dec 1995 03:30:08 -0800 (PST)
Received: from sbstark.cs.sunysb.edu (sbstark.cs.sunysb.edu [130.245.1.47])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id DAA28822
          for <current@freebsd.org>; Thu, 28 Dec 1995 03:29:47 -0800 (PST)
Received: (from root@localhost) by sbstark.cs.sunysb.edu (8.6.12/8.6.9) with UUCP id GAA07344; Thu, 28 Dec 1995 06:27:10 -0500
Received: (from gene@localhost) by starkhome.cs.sunysb.edu (8.6.11/8.6.9) id GAA20008; Thu, 28 Dec 1995 06:27:03 -0500
Date: Thu, 28 Dec 1995 06:27:03 -0500
From: Gene Stark <gene@starkhome.cs.sunysb.edu>
Message-Id: <199512281127.GAA20008@starkhome.cs.sunysb.edu>
To: bde@zeta.org.au
CC: peter@haywire.dialix.com, current@freebsd.org
In-reply-to: <199512281036.VAA25874@godzilla.zeta.org.au> (message from Bruce Evans on Thu, 28 Dec 1995 21:36:29 +1100)
Subject: Re: Tick, tock, adjust the clock
Sender: owner-current@freebsd.org
Precedence: bulk

>Note that this method doesn't work on 586's.  The tick length is now given
>by the macro CPU_THISTICKLEN(tick) instead of plain `tick', and on 586's
>the `tick' arg to the macro is ignored.  A similar effect can be obtained
>by adjusting `i586_ctr_rate' instead of `tick', but it would be better in
>all cases to adjust the 8254 clock's maximum count so that clock interrupts
>occur every 10000 +- 0.5 ideal ticks.  Then `tick' wouldn't need to be
>adjusted.

Awhile back when we communicated about this, you suggested the same thing.
I spent awhile trying kernels that had been compiled with modified values
for the constant that controls the 8254 clock count (I have forgotten
what it was called), but after a number of tries I was only able to make
the problem worse, rather than better.  When what seemed to be the correct
direction of change (smaller value to make the clock tick faster, larger
value to make the clock tick slower) didn't work, I tried an offset in the
opposite direction.  The results seemed very counterintuitive to me at the
time, making me think there must be some other adjustment mechanism at work
that I wasn't seeing.  After spending a bunch of time on it, I found that
adjusting `tick' made it work, so I did that.

The other bugs you just mentioned are one-time things that shouldn't
affect the ability of xntpd to sync up the time.

							- Gene