[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: why is poll+gettimeofday so slow?



Artur Grabowski <art_(_at_)_blahonga_(_dot_)_org> replied to
Gustavo Vieira =?iso-8859-1?q?Gon=E7alves?= Coelho Rios
    <gustavo_(_dot_)_rios_(_at_)_terra_(_dot_)_com_(_dot_)_br>
who wrote:
<deleted headers>
> 
> Gustavo Vieira Gon=E7alves Coelho Rios <gustavo_(_dot_)_rios_(_at_)_terra_(_dot_)_com_(_dot_)_br> writes=
> :
> 
<deleted source which reported time spent in poll.>
> >=20
> >=20
> > I got surprised when i ran it.
> >=20
> > Altough i asked poll to wait just 1 milisecond, the difference between
> > the timestamp where always higher the 10 miliseconds! Of course i tried
> > select, but it is even far from delivering microseconds precision.
> >=20
> > How may i get my select/poll/gettimeofday performance improved?
> 
> You can't. They are controlled by the internal periodic timeout clock
> and on all architechtures except the alpha, that clock is running at
> 100Hz.
> 
> It it possible to increase the resolution of the clock on some
> architectures, but that code is not really tested and might skew your
> clock badly or even crash the kernel.
> 
> Try looking at the HZ define in the kernel a see if you can make it highe=
> r.
> 
> //art

It may not suffice to crank up HZ, you may also have to muck around
with scheduling constants.  Increasing the resolution of the clock will
also increase clock interrupt overhead.  Past a certain point it will
take 100% of the CPU, hence nothing except the clock will run.  There
is a worse problem: if you really need to run things at a certain time
with microsecond resolution, you are asking the obsd scheduler to do
what it was never designed to do.  The obsd schedule was designed to
deliver acceptable interactive performance, and the scheduling contants
were mainly selected to "look nice" to human users.  You apparently
want a scheduler designed for "real-time" scheduling, and you are
certainly asking for accuracy in scheduling which wouldn't be visible to
human users.

You probably have 2 choices:
(1) analyze your problem: can it be designed as a device driver?
	If so, you may be able to run it under obsd, probably after hacking
	the clock code to implement high precision timeout code.
(2) select another OS that actually has real-time scheduling in it.
	"rtmach" aka real time mach might be interesting to look at:
		http://www-2.cs.cmu.edu/afs/cs.cmu.edu/project/art-6/www/rtmach.html
	There is an endless assortment of small commercial operating
	systems designed to deliver varying degrees of real-timeness;
	some come with source; some look something like Unix; some
	are neither.

It might help if you can better describe what problem you are
trying to solve.

				-Marcus Watts