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

[Valerio Bellizzomi]

On 11/02/2007, at 18.30, Sam Mason wrote:

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


The hardware clock on a PC uses a low cost time base oscillator. It is
imprecise in any case.
So why don't just grab the BIOS time-of-day when we need it?

val