select/poll/usleep precision on FreeBSD vs Linux vs OSX

Luigi Rizzo rizzo at iet.unipi.it
Thu Mar 1 01:05:01 UTC 2012


On Thu, Mar 01, 2012 at 11:33:46AM +1100, Bruce Evans wrote:
> On Wed, 29 Feb 2012, Luigi Rizzo wrote:
> 
> >I have always been annoyed by the fact that FreeBSD rounds timeouts
> >in select/usleep/poll in very conservative ways, so i decided to
> >try how other systems behave in this respect. Attached is a simple
> >program that you should be able to compile and run on various OS
> >and see what happens.
> 
> Many are broken, indeed.
> 
> The simple program isn't attached.
...

> >
> >	        |    Actual timeout
> >               |      select            | poll  | usleep|
> >	timeout | FBSD  | Linux | OSX    | FBSD  | FBSD  |
> >	usec    | 9.0   | Vbox  | 10.6   |  9.0  |  9.0  |
> >	--------+-------+-------+--------+-------+-------+
> >	    1      2000      99       6     0      2000
> >	   10      2000     109      15     0      2000
> >	   50      2000     149      66     0      2000
> >	  100      2000     196     133     0      2000
> >	  500      2000     597     617     0      2000
> >	 1000      2000    1103    1136    2000    2000
> >	 1001      3000    1103    1136    2000    3000 <---
> >	 1500      3000    1608    1631    2000    3000 <---
> >      2000	   3000    2096    2127    3000    3000
> >	 2001	   4000                    3000    4000 <---
> >	 3001	   5000                    4000    5000 <---
> >
> >Note how the rounding (poll has the timeout in milliseconds) affects
> 
> You must have synced with timer interrupts to get the above.  Timeouts

yes i have -- the test code does almost nothing after returning from
a select, on a system that does some amount of work times could be
up to 1000us shorter. Still a huge error on short timeouts.

I should also comment that these are average values on an otherwise
idle system -- i will try to post a histogram of the actual values,
it might well be that osx and linux have quantized values very
different from the average (though this would violate the specs,
so i suspect instead that they have some cheap one-shot timers).

For FreeBSD I have also rounded the bsd values (actual averages are -1/+3us
over 1sec experiments).

> timeouts at the cost of efficiency.  But I don't like timeouts.  When
> they are used a lot, they are a form of busy waiting.  This is only
> acceptable if you have CPU to burn).

sometimes you have no other way to get a notification.

> It remains to explain why the above results show that poll() but not
> select() is broken for small timeouts (they are turned into 0 us for

no it is just that my application that does the rounding down as the
API only accepts milliseconds.

Thanks for the extensive comments.

cheers
luigi


More information about the freebsd-arch mailing list