Hello Scott!

> That's not an accurate representation of how it works.  For a more
> in-depth explanation, I refer you to `The Design and Implementation of
> 4.4BSD' sections 3.4 and 3.6.  I'll summarize, but please understand that
> it's just that:  a summary.

I can't get this book from the library at my university. :-(

>  - On each clock `tick', we increment the system time by 1000000/HZ
>    microseconds.[*]
> 
>  - Scheduling and other kernel tasks (e.g. timeouts), as well
>    as per-process timers (real, profiling, virtual) need resolution finer
>    than a per-second tick.

I understand this, and i don't want to change the way this thing works.

>  - Some user programs require a monotonically increasing time of day.

a monotonically increasing funktion is something like this

1 2 3 3 4 5 6 6 7 7 8 9 ...

or like this 

1 2 3 4 5 5.5 6 7.1 8 9 ...

If the systemclock is set to be a little bit slower than the realtime, and
the systemclock is updateted by the RTC every minute, the systemtime will
increase monotonically.

> [*] Actually, we add a variable that is initially set to 1000000/HZ, but
> this is close enough for this part of the discussion.  See the reference
> to adjtime() in the last paragraph.

Think the adjtime() won't help, because I don't know when i lost an
interrupt.

> > 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. 
> 
> The system time is a side effect of the other kernel activities going on. 

Ah, now it makes sense, there is no process "calculating" the time, it is
just a "sytemstep-counter".

>  - Access to the RTC is expensive, and

Sorry, I don't know how difficult it is to get the time from the RTC and
how much processtime is lost.
How about a /dev/rtc ? So every process can call the RTC if it is in the
need of an exact time.

>  - We will see significant `jitter' in the time-of-day clock if we happen
>    to miss interrupts.

Yes, that's right. The time will jump forward (and with the right code
not backward, hopefully :-)) when it is time to update with the RTC.
I think the system will get in big trouble if the time jumps backwards
after an update occurded. So this has to be prevented.

> The latter will manifest itself as a clock that suddenly jumps forward as
> the RTC time is used to update the system time (assuming that's even
> practical, i.e. assuming RTC access takes an insignificant amount of
> time).  The adjtime() call is mentioned in the previously cited text as a

Well, i can't see that, if the systemtime is updateted every minute, think
this won't leads to heavy load. 
Don't know exactly how the RTC works, but i think i have to read a
64bit(?)counter form an adresse in the memory, calculate a little, and
update the systemtime.

> Hope this makes the issue a little more clear.

Only a little... ;-)

Bye,
	Christoph

Christoph Ewering         eweri@uni-paderborn.de
Husarenstrasse 48         Fon: 05254 12555
33104 Paderborn           www.uni-paderborn.de/Admin/eweri/