Casovani usleep versus select?

[Pavel Kankovsky]

On Fri, 28 Nov 2003, Ladislav Vaiz wrote:

> nasledujici program ceka ruznymi metodami jednu mikrosekundu. Je mi jasne,
> ze na i386 s casovacem 100Hz  bude doba cekani minimalne 10 milisekund.
> To sedi pro cekani funkci select. Proc ale usleep ceka 20ms?

Evidentne je to tak, ze se cas zaokrouhli na cela kvanta (v nasem pripade
10 ms), ale usleep(), ktery je implementovany pres syscall nanosleep(),
ceka zasadne o jedno kvantum dele nez select().

Skoro bych rekl, ze na svedomi to ma tento radek v kernel/timer.c:
  expire = timespec_to_jiffies(&t) + (t.tv_sec || t.tv_nsec);

Nekdo se asi snazil dosahnout toho, aby se vzdy cekalo nejmene zadanou
dobu -- viz poznamku v include/linux/time.h.

Problem je, ze ma-li byt skutecne zaruceno, ze se ceka nejmene zadany cas,
pak to nelze udelat o mnoho lepe: mam-li cekat 10 ms, pak musim pockat do
konce prave probihajiciho kvanta, coz je mene nez 10 ms, a pak jeste jedno
dalsi kvantum. Pokud by zacatky cekani byly v case rozlozeny nahodne, pak
bych takhle prumerne cekal 15 ms. Jenze program, ktery cekani spousti
porad dokola, bude nanosleep() vyvolavat temer vzdycky na zacatku kvanta,
cili prumerne bude cekat 20-delta ms.

Vylepsit by se na tom snad dalo to, ze by se nanosleep podival, kolik casu
zbyva do konce probihajiciho kvanta a o to by cekaci interval zkratil.
Desetimilisekundove cekani by sice porad trvalo skoro 20 ms, ale
devitimilisekundove by uz mohlo trvat jen 10 ms.

--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."