Subject: Re: Clockticks lost, why ?
To: None <port-mac68k@NetBSD.ORG>
From: Michael R. Zucca <mrz5149@cs.rit.edu>
List: port-mac68k
Date: 01/29/1997 01:31:47
>...
>> The RTC chip only has a resolution of 1 second. Certain calls in UNIX present
>> time with finer resolution. To emulate that you put a counter on the
>> video interrupt which fires every 60th of a second and you have 60th of
>> a second resolution.
>
>        OK. So, you write a process like xntp which, when system load allows,
>slowly aligns your high resolution clock with the low-resolution RTC chip.

Do-able in most circumstances. The thing that concerns me about this sort of
thing is "time warping". What happens when you have code checking the time
or relying on the time and while it's running, the ntp breaks in and warps
time forward or backward then you return...ooops! Sorry time isn't linear
anymore :) I suppose if you just want your freakin' clock to be correct
and don't plan on running time critical stuff then this is a trade-off you
can live with.

Just a matter of providing a set of RTC system calls and a daemon. That way,
if you need "perfect" timing you can just fail to run the rtc daemon.

>        Does anyone know it is possible to detect that a video interrupt
>has been missed? If so, it might be possible to automatically correct the
>time by adding a number of ticks to the counter.

Not that I can tell. I checked the 68020 manual. Missing one interrupt isn't
so much of a big deal. That interrupt gets serviced and the interrupt line
gets cleared. It's just that if you *shut off* interrupts and the video
device *wants* to interrupt two or more times, that's when you have a problem.
There are 3 lines (bits) that go into the 68020 for devices to tell the
68020 if there is an interrupt. Binary math is your problem. You can't make
a line "really high". :)

>        Yes, that is the optimal solution.

While semaphores are good, there is still going to be some code that just
must be executed with interrupts off.

I'm not so sure why SCSI is such a bad culprit. I thought most II's and later
had DMA scsi. Let the controller interrupt you when a DMA transfer is finished
and lock/release the buffer using a semaphore. Maybe I'm just over-simplifing.
 



_______________________________________________________________________
 Michael Zucca - mrz5149@rit.cs.rit.edu - http://www.rit.edu/~mrz5149/
 "I will choose a path that's clear. I will choose Freewill. "
  --Rush, Freewill
_______________________________________________________________________