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.
artur
diff -urNp streamdev.org/client/filter.c streamdev/client/filter.c --- streamdev.org/client/filter.c 2005-11-06 17:43:58.000000000 +0100 +++ streamdev/client/filter.c 2007-04-05 23:25:11.000000000 +0200 @@ -57,6 +57,7 @@ cStreamdevFilters::cStreamdevFilters(voi cThread("streamdev-client: sections assembler") { m_Active = false; m_RingBuffer = new cRingBufferLinear(MEGABYTE(1), TS_SIZE * 2, true); + m_RingBuffer->SetTimeouts(10, 10); Start(); }
@@ -111,8 +112,7 @@ void cStreamdevFilters::Action(void) { } } m_RingBuffer->Del(TS_SIZE); - } else - usleep(1); + } } }
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?
--- 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); } }
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.
-
Artur Skawina -
Stone