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

I don't think that you are looking at this correctly.  I must say that I am
not to familiar with xntp and how it works, I assume that it uses adjtime.
If you look at Sec 3.6 of the 4.4BSD book you will see that the time of the
system is never really adjusted, what happens is that the future speed of
the clock is adjusted so that the clock will sync to real time at some
point in the future.  I don't know what guarantees the system makes in
terms of the ability to measure intervals.  I don't think that the system
guarantees linear time: that would be perfect time.  What I believe it does
promise is monotonically increasing time, ie any two time stamps will have
the one occurring later in real world physical time being stamped as later
by the kernel, not necessarily by the correct amount, but ordered correctly.

---------
Christopher R. Bowman
crb@eng.umd.edu
My home page