[coyotos-dev] coyotos.sleep, sleepTill, the epoch

[Sam Mason]

On Fri, Feb 09, 2007 at 03:40:49PM -0500, Jonathan S. Shapiro wrote:
> I want to try to dis-entangle some of my confusion in this conversation.
> Really, it comes down to two very simple statements:
> 
>   1. It's not the kernel's job to tell you what time it is.
>   2. Even if it *is* the kernel's job, the kernel can't do that job.
> 
> In principle, the kernel can only do two things:
> 
>   1. Keep an accurate tick counter.
>   2. Record a baseline system wall-clock value that correlates to
>      the "zero point" on the tick counter.
> 
> The kernel cannot tell you what time it is in TAI, UTC, or anything
> else. For starters, most hardware doesn't have any sort of reference
> clock that is even approximately accurate. The most the kernel can do is
> record enough information that higher-level software may be able to
> clean up the mess or come up with an independently calibrated time.

Now you point all that out it seems kind of obvious!

I've still got a question about the coyotos.sleep interface, would it
help if the sleep and sleepTill operations returned the kernel's idea
of the current time?  There doesn't seem to be any way at the moment to
determine this or am I missing something obvious, again?

> In fact, it is *very* expensive for the kernel to maintain an accurate
> tick counter. Regrettably, the tick counter rates on most hardware
> scales up and down with the clock -- even in places (like the APIC)
> where it isn't *supposed* to do this. The end result of this is that you
> can have low power consumption or accurate time keeping, but you have to
> pick one.
> 
> Something you definitely do NOT want is a 1ms granularity interrupt to
> maintain a tick counter. On current hardware this will account for a
> measurable fraction of the machine.

Yes, I was very surprised when Linux got this!


  Sam