>Well, I don't think that this is silly. think it is silly to count the
>interrupts and when i reach 60 to add a second to the systemclock.
>So why don't i take 60 interrupts and then look what is in the RTC.
>You can share processtime with this interrupt, but i don't understand why
>use it to calculate the time. 

Well, nice, except that the RTC's resolution is 1 second. If you want timer
resolution smaller that one second then you're sort of out of luck.

>> If you're servicing a long SCSI interrupt and a video interrupt comes in,
>> you've essentially lost it. Basic problem: we need semaphores to protect
>> critical code rather than shutting off interrupts for hours at a time.
>
>Someone said that this won't help to get the right time.

Not necessarily. However, the less time it takes to service an interrupt
the more likely you are not to miss another one. Never mind the fact that
faster interrupt servicing speeds I/O :)

>By the way, i've started this thread, because I want to know why NetBSD
>can't hold the time and MacOS can. Now I understand why, but I still can't
>understand, why NetBSD uses an interrupt when every Mac has a RTC.
>The code to read the RTC exists, but it is only called at bootime.

See above. There are a few applications that really need timer resolution
smaller than a second. What else can I say. It's a trade-off. We want to
provide a service, smaller than 1 second timing, and we trade off totally
accurate corse timing.

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