Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!rice!sun-spots-request
From: ksp@maxwell.nde.swri.edu (Keith S. Pickens)
Newsgroups: comp.sys.sun
Subject: Re: 4/330 time problems
Keywords: Miscellaneous
Message-ID: <3066@brazos.Rice.edu>
Date: 14 Nov 89 15:57:38 GMT
Sender: root@rice.edu
Organization: Sun-Spots
Lines: 49
Approved: Sun-Spots@rice.edu
X-Refs:  Original: v8n192, Replies: v8n194
X-Sun-Spots-Digest: Volume 8, Issue 198, message 3 of 18

On Nov 13, 11:45am, dupuy@cs.columbia.edu wrote:

= We run NTP, and it seems only to be able to keep the clock within about
= 100 ms of our local secondary time servers.  So there's still some bad
= stuff happening with them thar clocks.

I have a 4/370 (same cpu as a 4/330) which has a discontinuous clock.  I
have watched the offset of the clock vs. a stable reference with ntp.  I
see a slow drift, which is to be expected, with one second jumps
superimposed on it.  These jumps occur about every 225-235 minutes.  I
have checked another machine (4/330) and observered the same `effect'.
The net result is that the system time is badly broken.  You can't
stablize it with ntp and I would expect that it will break things in weird
and wondrous ways.

Here is the test setup:

		   4/370
		  /
                 /
      time server
       Sun 3/180
       	        \
		 \
		  4/280

The same measurement was run on both the 4/280 (SunOS 4.0.1) and on the
4/370 (SunOS 4.0.3).  The 4/280 shows only a slow drift relative to the
reference system.  The 4/370 shows a slow drift and 1 second jumps
relative to the reference system.  This indicates that the problem is in
the 4/370 clock and not in the time server.

The same source code was used to build ntp on both the 4/370 and 4/280.

This has been pending with Sun software support for over a month.  Here is
the feedback I got a couple of weeks ago:

>From Sun (31 Oct 89):

= This problem has been assigned bugid number 1029022. Engineering is looking
= at the problem as a possible problem with the Sun-4/330 software and/or
= hardware. At this time, I can give you no other status information nor
= schedule for the resolution of the problem.

	-keith
	 ksp@maxwell.nde.swri.edu
	 maxwell!ksp

PS: I have some nice data on this problem.  If anyone wants it send me mail.