|
Home > Archive > Unix Programming > March 2004 > select() accuracy on Unix.
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
select() accuracy on Unix.
|
|
|
| Hi all.
i use select with timeout in unix (both HP and Redhat Linux), and it
seems to return before the timeout expires.
the difference is in microseconds, but i dont understand why does it
exist.
here's my code:
//////////////////////////////////
os_time_toolkit initialize;
os_time_and_date startTime_ = os_time_and_date::now();
timeval t;
t.tv_sec = 3;
t.tv_usec = 0;
select(1,NULL , NULL, NULL, &t);
os_time_and_date currentTime = os_time_and_date::now();
os_time_period elapsedTime = currentTime - startTime_;
////////////////////////////////////
the value of "elapsedTime" is sometimes 2.99xxx, which makes my
program think timeout has not expired yet.
as you can see, i use ObjectSpace for time measurement which may be
problematic here.
so my q are:
1. is it possible that select is not accurate, up to the last
microsecond?
2. if not, how do you suggest i should measure elapsed time?
Thanks a lot.
Ofira.
| |
| Materialised 2004-03-16, 2:36 pm |
| Ofira wrote:
> Hi all.
>
> i use select with timeout in unix (both HP and Redhat Linux), and it
> seems to return before the timeout expires.
> the difference is in microseconds, but i dont understand why does it
> exist.
>
> here's my code:
>
> //////////////////////////////////
> os_time_toolkit initialize;
>
> os_time_and_date startTime_ = os_time_and_date::now();
> timeval t;
> t.tv_sec = 3;
> t.tv_usec = 0;
>
> select(1,NULL , NULL, NULL, &t);
>
> os_time_and_date currentTime = os_time_and_date::now();
>
> os_time_period elapsedTime = currentTime - startTime_;
> ////////////////////////////////////
>
> the value of "elapsedTime" is sometimes 2.99xxx, which makes my
> program think timeout has not expired yet.
>
> as you can see, i use ObjectSpace for time measurement which may be
> problematic here.
>
> so my q are:
>
> 1. is it possible that select is not accurate, up to the last
> microsecond?
> 2. if not, how do you suggest i should measure elapsed time?
>
> Thanks a lot.
> Ofira.
Use POSIX pselect() for better accuracy.
| |
| Fletcher Glenn 2004-03-16, 2:36 pm |
|
Materialised wrote:
> Ofira wrote:
>
>
> Use POSIX pselect() for better accuracy.
POSIX or not, no program based timer can be accurate to the microsecond.
The problem is that UNIX is a multi-tasking system, and other tasks may
be running when the timer expires.
--
Fletcher Glenn
| |
| Barry Margolin 2004-03-16, 6:40 pm |
| In article <405751D9.6060907@removethisfoglight.com>,
Fletcher Glenn <fletcher@removethisfoglight.com> wrote:
> POSIX or not, no program based timer can be accurate to the microsecond.
> The problem is that UNIX is a multi-tasking system, and other tasks may
> be running when the timer expires.
But those effects should cause it to return late, not early as the OP
experienced.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
| |
| Peter Ammon 2004-03-16, 6:40 pm |
| Ofira wrote:
> Hi all.
>
> i use select with timeout in unix (both HP and Redhat Linux), and it
> seems to return before the timeout expires.
> the difference is in microseconds, but i dont understand why does it
> exist.
>
[...]
Out of sheer curiosity, what are you doing where a slightly trigger
happy select() causes problems for you?
--
Pull out a splinter to reply.
| |
| David Schwartz 2004-03-16, 6:40 pm |
|
"Ofira" <oshaer@ndsisrael.com> wrote in message
news:e53a489a.0403161059.5cda6eae@posting.google.com...
> i use select with timeout in unix (both HP and Redhat Linux), and it
> seems to return before the timeout expires.
This is correct behavior and part of the definition of 'select'. The
timeout is the *maximum* amount of time 'select' can block.
> the difference is in microseconds, but i dont understand why does it
> exist.
Because the kernel has some internal accuracy on its limitation. The
semantics of 'select' were designed to make it ideal for waiting for file
descriptors, not for a delay. So its delay semantics are not as good as they
are for, say, 'nanosleep'.
> here's my code:
>
> //////////////////////////////////
> os_time_toolkit initialize;
>
> os_time_and_date startTime_ = os_time_and_date::now();
> timeval t;
> t.tv_sec = 3;
> t.tv_usec = 0;
>
> select(1,NULL , NULL, NULL, &t);
>
> os_time_and_date currentTime = os_time_and_date::now();
>
> os_time_period elapsedTime = currentTime - startTime_;
> ////////////////////////////////////
>
> the value of "elapsedTime" is sometimes 2.99xxx, which makes my
> program think timeout has not expired yet.
What is your definition of "timeout has expired"? If you mean the amount
of time you asked to wait has passed, you can only find that out by checking
the clock. If you mean select returned because of the timeout, you can only
find that out by checking the return value of select.
> as you can see, i use ObjectSpace for time measurement which may be
> problematic here.
Definitely, if you expect the time to tell you why select returned! It
can't do that.
> so my q are:
>
> 1. is it possible that select is not accurate, up to the last
> microsecond?
It is not supposed to be. The timeout is a limit on how long it will
wait, at most.
> 2. if not, how do you suggest i should measure elapsed time?
I'm not sure I understand what you're trying to measure. If you want to
know why 'select' returned, look at its return value. If you want to know
how much time passed, look at the system clock.
DS
| |
| Erik Max Francis 2004-03-16, 8:36 pm |
| Ofira wrote:
> i use select with timeout in unix (both HP and Redhat Linux), and it
> seems to return before the timeout expires.
> the difference is in microseconds, but i dont understand why does it
> exist.
man select
(ii) The select function may update the timeout parame-
ter to indicate how much time was left. The pselect
function does not change this parameter.
...
timeout is an upper bound on the amount of time elapsed
before select returns.
The timeout means "wait no longer than this," not "wait exactly this."
--
__ Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
\__/ Here day fights with night.
-- (the last words of Victor Hugo)
| |
| Andrei Voropaev 2004-03-17, 9:46 am |
| On 2004-03-16, Ofira <oshaer@ndsisrael.com> wrote:
[...]
>
> 1. is it possible that select is not accurate, up to the last
> microsecond?
> 2. if not, how do you suggest i should measure elapsed time?
Usually I compare current time with the value stored in timer. If that
time was not reached yet, then I call another select. General purpose OS
does not gurantee that timers will return at exact time. So all my
applications are prepared to handle facts that my timers can be
triggered a bit later. To make life easier I just put together wrapper
library that registers timed event, and when timer expires calls
specified handler. Again this library only makes sure that the handler
is called not earlier than specified time. The handler might be called
later.
Andrei
| |
| Villy Kruse 2004-03-17, 9:46 am |
| On Tue, 16 Mar 2004 19:13:47 GMT,
Fletcher Glenn <fletcher@removethisfoglight.com> wrote:
>
> POSIX or not, no program based timer can be accurate to the microsecond.
> The problem is that UNIX is a multi-tasking system, and other tasks may
> be running when the timer expires.
>
Also, on most systems the time-out of select can only be accurate to the
time interval between timer intterrupts, which on many system is only 100
times a second, that is 10 ms or 10000 microseconds accuracy. Some newer
systems have many more timer interrupts per second and older systems may
get fewer than 100 interrupts per second. If the timer interrupts to
frequently the CPU won't do anything else but servicing those interrupts.
Villy
|
|
|
|
|