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
On Monday 28 July 2003 21:27, Steven Newbury wrote:
> While testing SCHED_SOFTRR with XMMS I had to modify XMMS slightly since it
> usually checks for uid 0 before enabling SCHED_RR.
Oh good, then you won't have any problem with modifying the kernel to put in a
printk or two ;-)
> 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,
Daniel Phillips wrote:
>
> > 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;
--
Takashi Iwai <[email protected]> SuSE Linux AG - http://www.suse.de
ALSA Developer ALSA Project - http://www.alsa-project.org
On Thursday 07 August 2003 18.31, Takashi Iwai wrote:
> At Thu, 7 Aug 2003 16:59:03 +0100,
>
> Daniel Phillips wrote:
> > > 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;
Another possibility - will XMMS lock its memory from swapping when running as
root? (Or are there any special allocation/IO rule for root?)
/RogerL
--
Roger Larsson
Skellefte?
Sweden
On Thu, 7 Aug 2003, Roger Larsson wrote:
> On Thursday 07 August 2003 18.31, Takashi Iwai wrote:
> > At Thu, 7 Aug 2003 16:59:03 +0100,
> >
> > Daniel Phillips wrote:
> > > > 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;
>
> 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