[comp.sys.sun] "date -a" bug? under SunOS4.1

domae@nrtc.northrop.com (10/08/90)

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).

I even attempted to write a little C program to exercise the adjtime
system call (code below). Well, the same thing happens.  As a side note,
using date without the -a option (to explicitly set the time) works as it
should.  Clearly, this points to the implementation of adjtime() in the
kernel.

>>	#include <sys/time.h>
>>
>>	main ()
>>	{
>>       	struct timeval foo;
>>
>>       	foo.tv_sec=20;
>>      	adjtime (&foo, (char *) 0);
>>	}

Has anyone else experienced this problem?  Is there a known fix?

Terry Domae
Northrop Research and Technology Center

domae@nrtc.northrop.com (Terry Domae) (11/01/90)

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