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

2007-04-07 Thread Stone

 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 --15 vdr w/streamdev+softdevice caused X to become
unresponsive; i had to reset the machine. X was barely usable even with
the
vdr client niced)

 does the new dynamic timer effect vdr's performance as well?

After increasing that streamdev 1us usleep I don't see much difference in
vdr (+streamdev+softdevice) performance. Haven't updated to highres timers
on the vdr server yet, but i doubt it will change much. (iirc vdr itself
limits the delays to =3ms).




I just enabled high res timers on my system and the timer accuracy is much
higher.  The response time is very accurate with this new option enabled.
But, the cpu temp seems to have increased by about 4 degrees.  I have now
enabled the associated option to high res timers (tickless system).  With
tickless enabled, the system seems to be just as responsive as before but
the cpu temp is back to normal.
___
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

2007-04-06 Thread Artur Skawina
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

2007-04-06 Thread Stone



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

2007-04-06 Thread Artur Skawina
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

2007-04-06 Thread Stone



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


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

2007-04-05 Thread Stone

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 slept
for one or more milliseconds.
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);
   }
}
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr