Path: utzoo!news-server.csri.toronto.edu!rutgers!ucsd!ucbvax!K.GP.CS.CMU.EDU!bww+
From: bww+@K.GP.CS.CMU.EDU (Bradley White)
Newsgroups: comp.protocols.time.ntp
Subject: Re: Summary: Previous time adjustment / tickadj / loss of sync
Message-ID: <13990.668752214@K.GP.CS.CMU.EDU>
Date: 12 Mar 91 04:30:14 GMT
References: <9103112130.AA17813@lightning.McRCIM.McGill.EDU>
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: bww+@CS.CMU.EDU
Distribution: inet
Organization: The Internet
Lines: 28

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

Just as it must in order to do the best job of slewing the time (without
some further support like, for example, adjtime2()).

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

> This is a separate problem

If you are losing interrupts with any regularity, forget about using NTP
to synchronize clocks---it will be continually confused by the shifting
frequency of the local clock.  Something coarser will suffice.

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

I assert that any event that takes longer than the time between two clock
interrupts to process should not be running at a priority higher than the
clock.

Bradley