limit streamdev client's ringbuffer timeouts to more sane values

  On 4/5/07, Artur Skawina <art_k@o2.pl> 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..10000us 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(10000) 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?
  

Stone wrote:
> On 4/5/07, *Artur Skawina* <art_k@o2.pl <mailto:art_k@o2.pl>> wrote:
>     With the high-res timers in kernel 2.6.21+ usleep(1) is no longer
>     treated as
>     usleep(10000) 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.000000000 -0700
> +++ streamdev/client/filter.c   2007-04-05 20:45: 44.000000000 -0700
> @@ -135,7 +135,7 @@
>                         }
>                         m_RingBuffer->Del(TS_SIZE);
>                 } else
> -                       usleep(1);
> +                       cCondWait::SleepMs(1);
>         }
>  }

sure, just changing it to 'usleep(10000)' works too. Is there a reason to avoid
the ringbuffer infrastructure?

artur
  

>
>
> sure, just changing it to 'usleep(10000)' 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. :)
  

Stone wrote:
> 
>     sure, just changing it to 'usleep(10000)' 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|10000)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
  

>
>
> I tried the 1us -> (1000|10000)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.
  

Stone wrote:
> 
> 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).

artur
  

> > 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.