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

[Valerio Bellizzomi]

On 12/02/2007, at 2.29, Sam Mason wrote:

>On Mon, Feb 12, 2007 at 02:54:33AM +0100, Valerio Bellizzomi wrote:
>> On 12/02/2007, at 1.05, Sam Mason wrote:
>> 
>> >On Mon, Feb 12, 2007 at 12:15:46AM +0100, Valerio Bellizzomi wrote:
>> >> >> 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.
>> >
>> >I think the main reason it was done under Linux was for scheduler
>> >improvements rather than increased timer/clock accuracy.
>> >
>> >> So why don't just grab the BIOS time-of-day when we need it?
>> >
>> >I think because you need to know the time surprisingly regularly, also
>> >as far as I can tell it will only give you the time to the nearest
>> >second anyway.  This is reasonable, but doesn't help the scheduler
much.
>> 
>> The tick counter is also surprisingly prone to variations, this doesn't
>> help too.
>
>I have a feeling I've been misinterpreting your messages, I'll try both
>of my new interpretations.
>
> 1) If this response is about the scheduler then I don't think it
> matters---as long as everything stays the same relative to each other.
>
> 2) You still need some way to determine what the kernel thinks the
> current number of elapsed milliseconds since the epoch has been.  If
> it's drifts a bit that doesn't matter.  The time daemon could still go
> to the RTC and get the current time or probably more likely use a time
> server.  If a computer isn't connected to a network it's less likely to
> care about accurate time.

In some standalone measurement applications where you need to know the
exact time when the measure was taken. It matters even if the drift is 1
ms !
Probably I am asking too much out of PC hardware.

val