Re: poll/select timout accuracy

Balaji Srinivasan (balaji@cplane.com)
Tue, 21 Jul 1998 11:12:49 -0700 (PDT)


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

Along with UTIME if you really need accurate performance then check
out KURT (KU Real Time Linux) at http://hegel.ittc.ukans.edu/projects/kurt

as far as the problem with the man page goes, i think what they meant
to say was that the timeout specified will be the amount of time that
the process will sleep if none of the file descriptors are ready...
its kind of misleading but i dont know how it can be corrected...

BTW I think the linux implementation of select (ie adding an extra
jiffy and rounding to the higher value) is the correct implementation of
the Posix standard...so i would think the other UNIXs are wrong...
(especially since most of the timer library calls use select to implement
the sleeping)

my $0.02
balaji

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

-
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