interruptible_sleep_on_timeout.
I made some experiements with both of them , and
under a medium load (24Mbit) , it seems that
the interruptible is more accurate. The schedule
has deviation of several milisecondsevery
50/100 samples (I totally took a batch of 150
samples - each sample is a 50 mili
am using is 2.4.18 .
I have made a small research and found 2 possibilities:
schedule_timeout
interruptible_sleep_on_timeout.
What wrong with?
msleep(50*HZ/1000);
Not sure if it's available in the ancient 2.4.18 version though.
I made some experiements with both
Hi,
I have a kernel thread which needs to be
woke-up every 50 mili seconds (un-conditionaly) to be used as
a periodic timer
The kernel versionI am using is 2.4.18
I have made a small research and found 2
possibilities:
schedule_timeout
interruptible_sleep_on_timeout.
I made some
Muli Ben-Yehuda wrote:
On Mon, May 02, 2005 at 07:31:23AM -0700, Gil Paz wrote:
Hi,
Does any one knows of limitations of using
interruptible_sleep_on_timeout in 2.4
Not sure what you mean? it's a kernel API, meant to be called in
certain ways and contexts. It's also a pretty lousy API
On Tue, May 03, 2005 at 08:49:54AM +0300, Gilad Ben-Yossef wrote:
It's still usefull if you want to block for a certain time period,
uncondtionality. For everything else there is
wait_event_interruptiple.
if you want to block unconditionally, wouldn't
msleep()/ssleep()/usleep() and friends be
Muli Ben-Yehuda wrote:
On Tue, May 03, 2005 at 08:49:54AM +0300, Gilad Ben-Yossef wrote:
It's still usefull if you want to block for a certain time period,
uncondtionality. For everything else there is
wait_event_interruptiple.
if you want to block unconditionally, wouldn't
On Tue, 3 May 2005, Gilad Ben-Yossef wrote:
if you want to block unconditionally, wouldn't
msleep()/ssleep()/usleep() and friends be a better idea?
Of course they are - if you're using a kernel version that has them,
such as 2.6, while the question was specifically for 2.4.
Yes, those functions
Peter wrote:
if you want to block unconditionally, wouldn't
msleep()/ssleep()/usleep() and friends be a better idea?
Of course they are - if you're using a kernel version that has them,
such as 2.6, while the question was specifically for 2.4.
Yes, those functions has been back-ported to 2.4,
On Tue, 3 May 2005, Gilad Ben-Yossef wrote:
2.4.26 has usleep and nanosleep. I am using both. 2.4.26 is one of the
Debian unstable kernels (also used by Knoppix 3.4).
We are talking about kernel API's, not system calls.
And you cannot use the existing mechanism that underlies the syscall,
Hi,
Does any one knows of limitations of using interruptible_sleep_on_timeout in 2.4
Thanks,
Gil__Do You Yahoo!?Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Mon, May 02, 2005 at 07:31:23AM -0700, Gil Paz wrote:
Hi,
Does any one knows of limitations of using
interruptible_sleep_on_timeout in 2.4
Not sure what you mean? it's a kernel API, meant to be called in
certain ways and contexts. It's also a pretty lousy API which should
not be used
11 matches
Mail list logo
