Is this patch for streamdev a direct result from selecting the new
Tickless System (Dynamic Ticks) option in kernel 2.6.21? If yes, then
CONFIG_HIGH_RES_TIMERS High Resolution Timer Support. Whether NO_HZ
makes
a difference I'm not sure, i ran into this w/ both options on.
(launching nice
Stone wrote:
On 4/5/07, *Artur Skawina* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
wrote:
With the high-res timers in kernel 2.6.21+ usleep(1) is no longer
treated as
usleep(1) and the streamdev client is almost unusable; it uses
most of the cpu
and causes hundreds
sure, just changing it to 'usleep(1)' works too. Is there a reason to
avoid
the ringbuffer infrastructure?
No reason in particular, I just wanted to test which one worked best with
performance. Thanks for the patch. :)
___
vdr mailing list
Stone wrote:
sure, just changing it to 'usleep(1)' works too. Is there a
reason to avoid
the ringbuffer infrastructure?
No reason in particular, I just wanted to test which one worked best
with performance. Thanks for the patch. :)
I tried the 1us - (1000|1)us sleep
I tried the 1us - (1000|1)us sleep approach first, before using the
ringbuffer timeouts -- saw no noticeable difference wrt performance.
10ms timeouts seemed to be enough (it's the resolution of a HZ==100
kernel)
and gave similar interrupt and cs numbers as w/ low-res timers.
Is this
On 4/5/07, Artur Skawina [EMAIL PROTECTED] wrote:
Well, the streamdev-client reads data from a ringbuffer and when there
isn't anything
to read it tries to sleep for 1us and loops. This wasn't a problem when
the timer
resolution was in the 1000..1us range (1000..100Hz); the usleep(1)
call