>
> > This is *very* ennoying. Anyone has an idea? What am I doing wrong?
> Get the UTIME patch, apply it to an appropriate kernel, and rebuild
> your kernel with UTIME enabled (and, preferably, APM disabled, so
> that UTIME can rely on the cycle counter). UTIME is microsecond-
> resolution timers; otherwise, you can only wake up from sleep/usleep/
> nanosleep at a timer interrupt.
I'll give it a shot.
>
> > The behaviour is exactly the same with select().
> Yup. The system doesn't happen to get an interrupt which can trigger
> the scheduler until the next scheduling interval, and the usual system
> call overhead makes this the scheduling interval *after* the one you want.
> Just as with sleep(2), you're guaranteed to sleep *at* *least* as long
> as you asked for, unless interrupted. So a short-term/portable
> solution is to just sleep for less time. The "right" solution is to
> not rely on the OS to guarantee more than it really does, possibly
> including patching the kernel to enable it to do what you want.
>
> http://hegel.ittc.ukans.edu/projects/utime/ is your friend...
Thank-you! this makes sense, and allows me to understand the drifts. But this
a bug -- I've never seen any Unix kernel behave like this. Or to the least,
the bug is that the man pages should reflect this abnormal behaviour.
In select(2), it is said that timeout is an upper bound on the amount of
time elapsed before select returns... Further a NOTE suggest that select
may be used as a fairly portable timer.
Jean-marie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html