Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!spool.mu.edu!uwm.edu!bionet!agate!ucbvax!LIGHTNING.MCRCIM.MCGILL.EDU!mouse
From: mouse@LIGHTNING.MCRCIM.MCGILL.EDU (der Mouse)
Newsgroups: comp.protocols.time.ntp
Subject: Re: Summary: Previous time adjustment / tickadj / loss of sync
Message-ID: <9103112130.AA17813@lightning.McRCIM.McGill.EDU>
Date: 11 Mar 91 21:30:48 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: inet
Organization: The Internet
Lines: 48

>> The "error" case is, in fact, a perfectly legitimate result of the
>> adjtime() call -- a previous adjustment hasn't had time to complete.
>> The program should not assume that the previous time adjustment has
>> completed.

> This, of course, completely misses the point.  The program has
> carefully crafted the adjtime() values so that the adjustment should
> have completed by the next time adjtime() is called.

Only because it assumes something about the way adjtime is implemented
(the tickadj value and the way it's used).

> The problem with SunOS is that someone else (the kernel) is doing
> adjtime()s behind your back.

Right.

>>	If synchronizing the system clock to an external standard, as
>>	when using NTP, the logic for slaving the software time to the
>>	TOD chip time should be disabled:

>>		# adb -w /vmunix
>>		dosynctodr?W 0
>>		$q
>>		#

> Again, this misses the point.

It fixes the problem mentioned above - that the kernel is re-skewing
the software time to match the hardware time.  It should deal with the
pseudo-adjtime you mentioned above.  To fix it right, of course, the
hardware clock should be reset correctly when adjtime() is used.

> The real problem is that clock interrupts are being lost.

This is a separate problem, not related to the kernel effectively doing
adjtime()s behind ntp's back.  (Not related except perhaps for their
being part of the same timekeeping implementation, that is.)  The
problem here is that some things (notably output to the default tty
emulator for the console) tend to lock out clock interrupts for
excessively long intervals.  (And I must admit, given how fast a SPARC
can blit things around, scrolling is *incredibly* slow.  Does it handle
each pixel separately or what?!)

					der Mouse

			old: mcgill-vision!mouse
			new: mouse@larry.mcrcim.mcgill.edu