Re: [vdr] [PATCH] limit streamdev client's ringbuffer timeouts to more sane values

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 pa

Re: [vdr] [PATCH] limit streamdev client's ringbuffer timeouts to more sane values

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

Re: [vdr] [PATCH] limit streamdev client's ringbuffer timeouts to more sane values

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 vdr

Re: [vdr] [PATCH] limit streamdev client's ringbuffer timeouts to more sane values

Stone wrote: > On 4/5/07, *Artur Skawina* <[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