Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!rice!rice!sun-spots-request
From: domae@nrtc.northrop.com (Terry Domae)
Newsgroups: comp.sys.sun
Subject: Re: "date -a" bug? under SunOS4.1
Keywords: SunOS
Message-ID: <1990Oct31.235604.22382@rice.edu>
Date: 1 Nov 90 00:19:56 GMT
Sender: sun-spots-request@rice.edu
Organization: Sun-Spots
Lines: 28
Approved: Sun-Spots@rice.edu
Originator: spots@titan.rice.edu
X-Sun-Spots-Digest: Volume 9, Issue 352, message 3
X-Original-Date: Wed, 10 Oct 90 07:17:08 -0700
X-Refs:  Original: v9n322

From the people whom I've received replies from, Nick Sayer has summarized
the problem and a patch in the best way.  His messages follows. 

| From:    Nick Sayer <mrapple@quack.sac.ca.us>
|
| In uop.sunspots you write:
| 
|| I've been having a problem using the "date -a" command under SunOS4.1.
|| More specifically, issuing a "date -a +20" does drift the clock 20
|| seconds, but then it drifts back again to the original time.  This problem
|| also seems to effect the operation of ntp (network time protocol).
| 
| The answer is to turn off the kernel variable "dosynctodr". The kernel
| is trying to keep the kernel's idea of time synced to the real-time
| clock. For operations with ntp (or xntpd in our case), this is not
| desirable. You also should severely lower the setting of the
| variable "tickadj."

For my Sparcstation1, I used adb to write a new kernel with "dosynctodr"
set to zero, and "tickadj" to 5 (as recommended by the ntp documentation).
This has fixed the problem for the moment, however I think SUN needs to
make "adjtime" set both the clock variable as well as the real-time clock
as a general solution.

Thanks for everyone who sent replies!

Terry Domae
Northrop Research and Technology Center