Re: [vdr] [PATCH] limit streamdev client's ringbuffer timeouts to more sane values
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 of thousands context switches per second. This gets rid of the almost-busy-loop. How about his approach? --- streamdev/client/filter.c.orig 2007-04-05 20:45:04.0 -0700 +++ streamdev/client/filter.c 2007-04-05 20:45: 44.0 -0700 @@ -135,7 +135,7 @@ } m_RingBuffer-Del(TS_SIZE); } else - usleep(1); + cCondWait::SleepMs(1); } } sure, just changing it to 'usleep(1)' works too. Is there a reason to avoid the ringbuffer infrastructure? artur ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
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@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
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 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. artur ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
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 patch for streamdev a direct result from selecting the new Tickless System (Dynamic Ticks) option in kernel 2.6.21? If yes, then does the new dynamic timer effect vdr's performance as well? Best Regards. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
