Path: utzoo!utgpu!cunews!bnrgate!brtph3!brchh104!brchs1!bnr.ca!rice.edu!sun-spots-request
From: mb@sparrms.ists.ca (Mike Bell)
Newsgroups: comp.sys.sun
Subject: Clock (adjtime()) weirdness
Keywords: Miscellaneous
Message-ID: <1724@brchh104.bnr.ca>
Date: 21 Feb 91 20:15:00 GMT
Sender: news@brchh104.bnr.ca
Organization: Sun-Spots
Lines: 22
Approved: Sun-Spots@rice.edu
X-Original-Date: Thu, 14 Feb 91 16:07:28 EST
X-Sun-Spots-Digest: Volume 10, Issue 46, message 3
X-Note: Submissions: sun-spots@rice.edu, Admin: sun-spots-request@rice.edu

One of our Suns (an ancient 3/260) exhibits odd behaviour when the clock
time is adjusted using the adjtime(2) system call. The observed behaviour
is this:

    adjtime( &delta, NULL ) is called where

		delta.tv_sec = 0;
		delta.tv_usec = -23500000; /* approx */

The clock time slowly adjusts to "lose" 23.5 secs, then, when it has done
this, *rapidly* adjusts again until it is back to 23.5 secs out*!

This also applies to the date -a command doing the same thing.

However, attempts to set the clock directly to the correct time do not
appear to encounter this problem.

There aren't any rdates or local processes running (as far as I can tell)
which reset the time... The same procedures work OK on other machines on
the network.

Anybody got any theories? I've run out of ideas... 


Brought to you by Super Global Mega Corp .com