SCHED_SOFTRR patch
I personally see your SCHED_SOFTRR as the correct solution for multimedia applications. But as it is currently tuned I have been unable to get it to work adequately with a relatively undemanding program, XMMS. I say undemanding because XMMS only uses about 2-4% CPU time on my test machine (P3/933MHz) when playing mp3's.
While testing SCHED_SOFTRR with XMMS I had to modify XMMS slightly since it usually checks for uid 0 before enabling SCHED_RR.
Under 2.6.0-test1 based kernels I have experienced quite a lote of drop-outs with XMMS playing mp3's with a moderate load, however, when run as root (with SCHED_RR) I encountered no drop-outs at all. When using SOFTRR under I had very choppy playback when the machine was under load. It was a constant jittering more than intermittent drop-outs.
I have been using a 2.6.0-test2-O10int based kernel in my latest tests.
With 2.6.0-test2-O10int it is very hard to get drop-outs unless I run it with SCHED_SOFTRR! The jitteriness is gone but a moderate load causes dropouts, much like non SCHED_RR on 2.6.0-test1 based kernels. SCHED_RR still runs perfectly though. It could be that SCHED_SOFTRR is being too "tight" with the CPU time it is giving the Real-Time thread.
I have tried various values for the SCHED_TS_KSOFTRR, MIN_SRT_TIMESLICE, MAX_SRT_TIMESLICE constants, but have been as yet unable to find values that produce a good result.
The lattest.c program does show that SOFT_RR is working as does top which shows RT priority for XMMS.
=====
Steve
__________________________________________________
Yahoo! Plus - For a better Internet experience
http://uk.promotions.yahoo.com/yplus/yoffer.html
Quoted 2 lines · Steven Newbury
While testing
SCHED_SOFTRRwith XMMS I had to modify XMMS slightly since it usually checks for uid 0 before enablingSCHED_RR.
Oh good, then you won't have any problem with modifying the kernel to put in a printk or two ;-)
Quoted 5 lines
Under 2.6.0-test1 based kernels I have experienced quite a lote of drop-outs with XMMS playing mp3's with a moderate load, however, when run as root (with
SCHED_RR) I encountered no drop-outs at all. When using SOFTRR under I had very choppy playback when the machine was under load. It was a constant jittering more than intermittent drop-outs.
According to me, this should not happen, since your cpu usage is well below what is supposed to be the cutoff for the realtime slice. I've only seen one report like yours, where SOFTRR isn't working as intended. On the other hand, I've missed a lot of lkml traffice lately, so there could be more.
What kind of system is this? Is it a laptop with speedstep?
Regards,
Daniel
At Thu, 7 Aug 2003 16:59:03 +0100,
Quoted 11 lines · Daniel Phillips
Quoted 6 lines
Under 2.6.0-test1 based kernels I have experienced quite a lote of drop-outs with XMMS playing mp3's with a moderate load, however, when run as root (with
SCHED_RR) I encountered no drop-outs at all. When using SOFTRR under I had very choppy playback when the machine was under load. It was a constant jittering more than intermittent drop-outs.According to me, this should not happen, since your cpu usage is well below what is supposed to be the cutoff for the realtime slice. I've only seen one report like yours, where SOFTRR isn't working as intended. On the other hand, I've missed a lot of lkml traffice lately, so there could be more.
looking at the source code of xmms and found that xmms OSS output plugin behaves differently if the process is SCHED_RR.
when xmms is started with SCHED_RR, it won't create an (another) audio thread. perhaps this explains also the difference found in some cases.
well, i'm not 100% sure about this theory, now needs to practice :) please try to turn off the check of SCHED_RR in xmms/Output/OSS/audio.c, something like:
realtime = xmms_check_realtime_priority();
replaced with
realtime = 0;
Signature · 2 lines
Takashi Iwai <[email protected]> SuSE Linux AG - www.suse.de ALSA Developer ALSA Project - www.alsa-project.org
Re: SCHED_SOFTRR patch (memory lock?)
Quoted 26 lines · Takashi Iwai
At Thu, 7 Aug 2003 16:59:03 +0100,
Quoted 7 lines · Daniel Phillips
Quoted 6 lines
Under 2.6.0-test1 based kernels I have experienced quite a lote of drop-outs with XMMS playing mp3's with a moderate load, however, when run as root (with
SCHED_RR) I encountered no drop-outs at all. When using SOFTRR under I had very choppy playback when the machine was under load. It was a constant jittering more than intermittent drop-outs.Quoted 5 lines
According to me, this should not happen, since your cpu usage is well below what is supposed to be the cutoff for the realtime slice. I've only seen one report like yours, where SOFTRR isn't working as intended. On the other hand, I've missed a lot of lkml traffice lately, so there could be more.
looking at the source code of xmms and found that xmms OSS output plugin behaves differently if the process is
SCHED_RR.
when xmms is started withSCHED_RR, it won't create an (another) audio thread. perhaps this explains also the difference found in some cases.well, i'm not 100% sure about this theory, now needs to practice :) please try to turn off the check of
SCHED_RRinxmms/Output/OSS/audio.c, something like:
Quoted 5 lines
realtime = xmms_check_realtime_priority();replaced with
realtime = 0;
Another possibility - will XMMS lock its memory from swapping when running as root? (Or are there any special allocation/IO rule for root?)
/RogerL
Signature · 3 lines
Roger Larsson Skellefteå Sweden
Re: SCHED_SOFTRR patch (memory lock?)
Quoted 27 lines · Roger Larsson
Quoted 26 lines · Takashi Iwai
At Thu, 7 Aug 2003 16:59:03 +0100,
Quoted 7 lines · Daniel Phillips
Quoted 6 lines
Under 2.6.0-test1 based kernels I have experienced quite a lote of drop-outs with XMMS playing mp3's with a moderate load, however, when run as root (with
SCHED_RR) I encountered no drop-outs at all. When using SOFTRR under I had very choppy playback when the machine was under load. It was a constant jittering more than intermittent drop-outs.Quoted 5 lines
According to me, this should not happen, since your cpu usage is well below what is supposed to be the cutoff for the realtime slice. I've only seen one report like yours, where SOFTRR isn't working as intended. On the other hand, I've missed a lot of lkml traffice lately, so there could be more.
looking at the source code of xmms and found that xmms OSS output plugin behaves differently if the process is
SCHED_RR.
when xmms is started withSCHED_RR, it won't create an (another) audio thread. perhaps this explains also the difference found in some cases.well, i'm not 100% sure about this theory, now needs to practice :) please try to turn off the check of
SCHED_RRinxmms/Output/OSS/audio.c, something like:
Quoted 8 lines
Quoted 5 lines
realtime = xmms_check_realtime_priority();replaced with
realtime = 0;Another possibility - will XMMS lock its memory from swapping when running as root? (Or are there any special allocation/IO rule for root?)
Gee, it was 100F last time I saw this thread :-)
Yes, xmms behave in two completely different ways depending on the fact that it is or it is not running RR. With RR it writes directly to the dsp, while w/out it creates a thread that handles an output buffer. Then thread then does write to the dsp when the buffer has something to be written.
- Davide