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

[Sam Mason]

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.

I hope one of those makes more sense?


  Sam