poll(2) timeout accuracy?

Hello,

Can anyone comment on poll(2) implementations regarding the timeout
value?  Supposing that there's nothing available to read or write, is
it possible that 'diff' below gets assigned a value that's less than
'timeout'?

gettimeofday(&start, NULL);
res = poll(pfds, max, timeout);
if (res < 0)
abort();
gettimeofday(&end, NULL);
diff = (end.tv_sec - start.tv_sec) * 1000;
diff += (end.tv_usec - start.tv_usec) / 1000;

Using a timeout between 1 to 4, I sometimes get diff=0 in FreeBSD 5.4
on a 233 MHz Pentium machine.  So, well, seems like that settles the
question:)

So, what I'm really interested in is if this is to be expected, if
poll(2) behave strangely on this machine, or if it's an indication of
a bug or something else that I've not thought about...

Staffan

Staffan Ulfberg wrote:
> Can anyone comment on poll(2) implementations regarding the timeout
> value?  Supposing that there's nothing available to read or write, is
> it possible that 'diff' below gets assigned a value that's less than
> 'timeout'?
>
>         gettimeofday(&start, NULL);
>         res = poll(pfds, max, timeout);
>         if (res < 0)
>                 abort();
>         gettimeofday(&end, NULL);
>         diff = (end.tv_sec - start.tv_sec) * 1000;
>         diff += (end.tv_usec - start.tv_usec) / 1000;
>
> Using a timeout between 1 to 4, I sometimes get diff=0 in FreeBSD 5.4
> on a 233 MHz Pentium machine.  So, well, seems like that settles the
> question:)

It depends on res. If res is not zero, we are in the specs ;-) The fact
that there is nothing to read or to write does not imply that res is
zero: poll can return also on other events (e.g. channel closed).

If res is zero, then we must take the time resolution of gettimeofday (don't
forget that the timeout of the poll is expressed in milliseconds). The fact
that gettimeofday returns a structure that contains a "microseconds" field
does not necessarily imply that the value returned is *accurate* to the
microsecond...

Some gettimeofday man page clearly state that:
> The resolution of  the  system  clock  is  hardware
> dependent; the time may be updated continuously or in clock ticks.

Ciao,
--
Roberto Divia`              Love at first sight is one of the greatest
Dep:PH Bat:53 Mailbox:C02110      labour-saving devices the world has ever s
een
Route de Meyrin 385               ------------------------------------------
---
Case Postale                                Phone:  +41-22-767-4994
CH-1211 Geneve 23 CERN                      Fax:    +41-22-767-9585
Switzerland                                 E-Mail: Roberto.Divia@cern.ch

In article <87fyxjhzev.fsf@multivac.fatburen.org>,
Staffan Ulfberg <staffan@ulfberg.se> wrote:

> Hello,
>
> Can anyone comment on poll(2) implementations regarding the timeout
> value?  Supposing that there's nothing available to read or write, is
> it possible that 'diff' below gets assigned a value that's less than
> 'timeout'?
>
>         gettimeofday(&start, NULL);
>         res = poll(pfds, max, timeout);
>         if (res < 0)
>                 abort();
>         gettimeofday(&end, NULL);
>         diff = (end.tv_sec - start.tv_sec) * 1000;
>         diff += (end.tv_usec - start.tv_usec) / 1000;
>
> Using a timeout between 1 to 4, I sometimes get diff=0 in FreeBSD 5.4
> on a 233 MHz Pentium machine.  So, well, seems like that settles the
> question:)
>
> So, what I'm really interested in is if this is to be expected, if
> poll(2) behave strangely on this machine, or if it's an indication of
> a bug or something else that I've not thought about...

There have been cases where streams unexpectedly report they're readble
when they're actually not, so poll() or select() returns early.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Barry Margolin <barmar@alum.mit.edu> writes:

> There have been cases where streams unexpectedly report they're readble
> when they're actually not, so poll() or select() returns early.

Well, this seems to be what happens here.  Would you know where these
cases have occurred?  (OS, versions, etc?)

Staffan

"Staffan Ulfberg" <staffan@ulfberg.se> wrote in message
news:87fyxjhzev.fsf@multivac.fatburen.org...

> Can anyone comment on poll(2) implementations regarding the timeout
> value?  Supposing that there's nothing available to read or write, is
> it possible that 'diff' below gets assigned a value that's less than
> 'timeout'?

Yes.

>        gettimeofday(&start, NULL);
>        res = poll(pfds, max, timeout);
>        if (res < 0)
>                abort();
>        gettimeofday(&end, NULL);
>        diff = (end.tv_sec - start.tv_sec) * 1000;
>        diff += (end.tv_usec - start.tv_usec) / 1000;
>
> Using a timeout between 1 to 4, I sometimes get diff=0 in FreeBSD 5.4
> on a 233 MHz Pentium machine.  So, well, seems like that settles the
> question:)

This is not supposed to happen, assuming 'res' is zero unless something
changed the real-time clock during the call to 'poll'. When this happens, is
'res' zero or somethign else?

> So, what I'm really interested in is if this is to be expected, if
> poll(2) behave strangely on this machine, or if it's an indication of
> a bug or something else that I've not thought about...

The 'gettimeofday' clock gives you the systems best guess of the current
actual wall clock time. The delay in 'poll', however, is the best guess at
waiting that amount of real time. The two don't have to correlate, and you
can think of realistic situations where they wouldn't. The most obvious
would be if the time is changed during the call to 'poll'.

However, if 'poll' return zero, the elapsed time is supposed to be
greater than the timeout. However, the difference between two calls to
'gettimeofday' is only a guess at the elapsed time. It's perfectly legal,
for example, for a machine to have higher resolution in its 'poll' timeout
than in 'gettimeofday', so a 'poll' with a microsecond delay might show the
same result from 'gettimeofday' after the call as before.

DS

"David Schwartz" <davids@webmaster.com> writes:

>    However, if 'poll' return zero, the elapsed time is supposed to be
>greater than the timeout. However, the difference between two calls to
>'gettimeofday' is only a guess at the elapsed time. It's perfectly legal,
>for example, for a machine to have higher resolution in its 'poll' timeout
>than in 'gettimeofday', so a 'poll' with a microsecond delay might show the
>same result from 'gettimeofday' after the call as before.

Poll has at best a millisecond delay (minimum granulrity); the OS
may run with a 100Hz clock so the OS sometimes has no choice but
to wait for two clock ticks (it's generally never right to wait
just one clock tick except in the interval timers).

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.