xmms (audio) skipping in 2.5 (not 2.4)

xmms (audio) skipping in 2.5 (not 2.4)

[Martin J. Bligh]

OK, so I finally took the plunge, and put 2.5 on my main desktop as well as
just the lab machines ;-)

Generally seems to work very well, and VM performance is much more stable
than 2.4 ... but xmms seems to skip if I just waggle the scrollbar in some
windows. This happens most in my email client (which is Mulberry), but
other things show it to a more limited extent.

The audio pauses happen on a simple window scroll down, without intensive
CPU background activity ... they're very short in duration, which makes it
*feel* more like the audio buffer is too small than a scheduler problem,
but I'm just guessing really.

So ... is there any easy way I can diagnose this? Does anyone else have a
similar problem?

Audio is SiS SI7012 ALSA driver emulating OSS. Athalon 2100, 512Mb.
kernel = 2.5.63-mjb2

M.

PS. In the unlikely even that anyone's particularly fascinated by one app,
Mulberry isn't free, but a free demo can be downloaded from
http://www.cyrusoft.com if you wade through the registration ... as I say,
unlikely ;-)

Re: xmms (audio) skipping in 2.5 (not 2.4)

[Con Kolivas]

On Tue, 4 Mar 2003 04:25 pm, Martin J. Bligh wrote:
> OK, so I finally took the plunge, and put 2.5 on my main desktop as well as
> just the lab machines ;-)
>
> Generally seems to work very well, and VM performance is much more stable
> than 2.4 ... but xmms seems to skip if I just waggle the scrollbar in some
> windows. This happens most in my email client (which is Mulberry), but
> other things show it to a more limited extent.
>
> The audio pauses happen on a simple window scroll down, without intensive
> CPU background activity ... they're very short in duration, which makes it
> *feel* more like the audio buffer is too small than a scheduler problem,
> but I'm just guessing really.
>
> So ... is there any easy way I can diagnose this? Does anyone else have a
> similar problem?

Most of us who have worked with an O(1) scheduler based kernel have found this 
at various times. See the previous discussion with akpm about the 
interactivity estimator. Akpm found that decreasing the maximum timeslice 
duration would blunt the effect of the interactivity estimator giving 
preference to the "wrong" task. In 2.4.20-ck4 I avoid this problem with the 
"desktop tuning" of making the max timeslice==min timeslice. Try an -mm 
kernel with the scheduler tunables patch and try playing with the max 
timeslice. Most have found that <=25 will usually stop these skips. The 
default max timeslice of 300ms is just too long for the desktop and 
interactivity estimator.
 
Con

Re: xmms (audio) skipping in 2.5 (not 2.4)

[Martin J. Bligh]

>> So ... is there any easy way I can diagnose this? Does anyone else have a
>> similar problem?
> 
> Most of us who have worked with an O(1) scheduler based kernel have found
> this  at various times. See the previous discussion with akpm about the 
> interactivity estimator. Akpm found that decreasing the maximum timeslice 
> duration would blunt the effect of the interactivity estimator giving 
> preference to the "wrong" task. In 2.4.20-ck4 I avoid this problem with
> the  "desktop tuning" of making the max timeslice==min timeslice. Try an
> -mm  kernel with the scheduler tunables patch and try playing with the
> max  timeslice. Most have found that <=25 will usually stop these skips.
> The  default max timeslice of 300ms is just too long for the desktop and 
> interactivity estimator.

Heh, cool. I have the same patch in my tree too, fixed it without rebooting
even ;-) Still a *tiny* bit of skipping, but infinitely better than it was.
Thanks very much,

M.

Re: xmms (audio) skipping in 2.5 (not 2.4)

[Con Kolivas]

On Tue, 4 Mar 2003 04:52 pm, Martin J. Bligh wrote:
> >> So ... is there any easy way I can diagnose this? Does anyone else have
> >> a similar problem?
> >
> > Most of us who have worked with an O(1) scheduler based kernel have found
> > this  at various times. See the previous discussion with akpm about the
> > interactivity estimator. Akpm found that decreasing the maximum timeslice
> > duration would blunt the effect of the interactivity estimator giving
> > preference to the "wrong" task. In 2.4.20-ck4 I avoid this problem with
> > the  "desktop tuning" of making the max timeslice==min timeslice. Try an
> > -mm  kernel with the scheduler tunables patch and try playing with the
> > max  timeslice. Most have found that <=25 will usually stop these skips.
> > The  default max timeslice of 300ms is just too long for the desktop and
> > interactivity estimator.
>
> Heh, cool. I have the same patch in my tree too, fixed it without rebooting
> even ;-) Still a *tiny* bit of skipping, but infinitely better than it was.

Try decreasing prio_bonus_ratio to 15 as well

> Thanks very much,

Pleasure

Con

Re: xmms (audio) skipping in 2.5 (not 2.4)

[Martin J. Bligh]

>> >> So ... is there any easy way I can diagnose this? Does anyone else
>> >> have a similar problem?
>> > 
>> > Most of us who have worked with an O(1) scheduler based kernel have
>> > found this  at various times. See the previous discussion with akpm
>> > about the interactivity estimator. Akpm found that decreasing the
>> > maximum timeslice duration would blunt the effect of the interactivity
>> > estimator giving preference to the "wrong" task. In 2.4.20-ck4 I avoid
>> > this problem with the  "desktop tuning" of making the max
>> > timeslice==min timeslice. Try an -mm  kernel with the scheduler
>> > tunables patch and try playing with the max  timeslice. Most have
>> > found that <=25 will usually stop these skips. The  default max
>> > timeslice of 300ms is just too long for the desktop and interactivity
>> > estimator.
>> 
>> Heh, cool. I have the same patch in my tree too, fixed it without
>> rebooting even ;-) Still a *tiny* bit of skipping, but infinitely better
>> than it was.
> 
> Try decreasing prio_bonus_ratio to 15 as well

Doesn't seem to make much difference, actually.
But "waggle scrollbar a bit" isn't very scientific .. ;-)
Does contest (or anything else) measure this kind of thing more precisely?

M.

Re: xmms (audio) skipping in 2.5 (not 2.4)

[Con Kolivas]

On Tue, 4 Mar 2003 06:48 pm, Martin J. Bligh wrote:
> >> >> So ... is there any easy way I can diagnose this? Does anyone else
> >> >> have a similar problem?
> >> >
> >> > Most of us who have worked with an O(1) scheduler based kernel have
> >> > found this  at various times. See the previous discussion with akpm
> >> > about the interactivity estimator. Akpm found that decreasing the
> >> > maximum timeslice duration would blunt the effect of the interactivity
> >> > estimator giving preference to the "wrong" task. In 2.4.20-ck4 I avoid
> >> > this problem with the  "desktop tuning" of making the max
> >> > timeslice==min timeslice. Try an -mm  kernel with the scheduler
> >> > tunables patch and try playing with the max  timeslice. Most have
> >> > found that <=25 will usually stop these skips. The  default max
> >> > timeslice of 300ms is just too long for the desktop and interactivity
> >> > estimator.
> >>
> >> Heh, cool. I have the same patch in my tree too, fixed it without
> >> rebooting even ;-) Still a *tiny* bit of skipping, but infinitely better
> >> than it was.
> >
> > Try decreasing prio_bonus_ratio to 15 as well
>
> Doesn't seem to make much difference, actually.
> But "waggle scrollbar a bit" isn't very scientific .. ;-)
> Does contest (or anything else) measure this kind of thing more precisely?

Last time I tried to do a whole swag of tunables it was showing differences 
but I was plagued by memory leaks ruining the data. I'll try again in the 
near future. Also Bill Davidsen's trivial response benchmark may show 
something too.

Con

Re: xmms (audio) skipping in 2.5 (not 2.4)

[Giuliano Pochini]

> Try an -mm 
> kernel with the scheduler tunables patch and try playing with the max
> timeslice. Most have found that <=25 will usually stop these skips. The
> default max timeslice of 300ms is just too long for the desktop and
> interactivity estimator.

IMHO 300ms is way too much. Timeslice should be in the 10-50ms range
to get good interactive performance. Why is it so long ?

Bye.

Re: xmms (audio) skipping in 2.5 (not 2.4)

[Andrew McGregor]

Per chance, do you have an NVidia graphics card and Maestro 3 or USB audio? 
If so, you're possibly getting DMA starvation.  There are games you can 
play with the PCI latency timers to help with this, but I cannot recall the 
details; searching around for Dell Inspiron laptop audio issues might find 
them.  I just replaced the machine I saw this on, so I can't help anymore.

Andrew

--On Tuesday, 4 March 2003 7:15 p.m. +1100 Con Kolivas <kernel@kolivas.org> 
wrote:

> On Tue, 4 Mar 2003 06:48 pm, Martin J. Bligh wrote:
>> >> >> So ... is there any easy way I can diagnose this? Does anyone else
>> >> >> have a similar problem?
>> >> >
>> >> > Most of us who have worked with an O(1) scheduler based kernel have
>> >> > found this  at various times. See the previous discussion with akpm
>> >> > about the interactivity estimator. Akpm found that decreasing the
>> >> > maximum timeslice duration would blunt the effect of the
>> >> > interactivity estimator giving preference to the "wrong" task. In
>> >> > 2.4.20-ck4 I avoid this problem with the  "desktop tuning" of
>> >> > making the max timeslice==min timeslice. Try an -mm  kernel with
>> >> > the scheduler tunables patch and try playing with the max
>> >> > timeslice. Most have found that <=25 will usually stop these skips.
>> >> > The  default max timeslice of 300ms is just too long for the
>> >> > desktop and interactivity estimator.
>> >>
>> >> Heh, cool. I have the same patch in my tree too, fixed it without
>> >> rebooting even ;-) Still a *tiny* bit of skipping, but infinitely
>> >> better than it was.
>> >
>> > Try decreasing prio_bonus_ratio to 15 as well
>>
>> Doesn't seem to make much difference, actually.
>> But "waggle scrollbar a bit" isn't very scientific .. ;-)
>> Does contest (or anything else) measure this kind of thing more
>> precisely?
>
> Last time I tried to do a whole swag of tunables it was showing
> differences  but I was plagued by memory leaks ruining the data. I'll try
> again in the  near future. Also Bill Davidsen's trivial response
> benchmark may show  something too.
>
> Con
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>
>

Re: xmms (audio) skipping in 2.5 (not 2.4)

[Anton Blanchard]

> OK, so I finally took the plunge, and put 2.5 on my main desktop as well as
> just the lab machines ;-)
> 
> Generally seems to work very well, and VM performance is much more stable
> than 2.4 ... but xmms seems to skip if I just waggle the scrollbar in some
> windows. This happens most in my email client (which is Mulberry), but
> other things show it to a more limited extent.
> 
> The audio pauses happen on a simple window scroll down, without intensive
> CPU background activity ... they're very short in duration, which makes it
> *feel* more like the audio buffer is too small than a scheduler problem,
> but I'm just guessing really.

Are you running debian? It likes to nice -10 the X server. Renicing it
back to 0 fixes my xmms skips with 2.5.

Anton

Re: xmms (audio) skipping in 2.5 (not 2.4)

[Maciej Soltysiak]

> Are you running debian? It likes to nice -10 the X server. Renicing it
> back to 0 fixes my xmms skips with 2.5.
Nice, good to know that.

> Anton
Maciej

Re: xmms (audio) skipping in 2.5 (not 2.4)

[Sean Neakums]

commence  Anton Blanchard quotation:

> Are you running debian? It likes to nice -10 the X server. Renicing it
> back to 0 fixes my xmms skips with 2.5.

You can alter this permanently with 'dpkg-reconfigure xserver-common';
if you elect not to have /etc/X11/Xwrapper.config managed by debconf,
simply edit it directly.

-- 
 /                          |
[|] Sean Neakums            | Size *does* matter.
[|] <sneakums@zork.net>     | That's why I use Emacs.
 \                          |

Re: xmms (audio) skipping in 2.5 (not 2.4)

[Martin J. Bligh]

> Per chance, do you have an NVidia graphics card and Maestro 3 or USB
> audio? 

Neither ...


M.

Re: xmms (audio) skipping in 2.5 (not 2.4)

[Martin J. Bligh]

> Anton:
>
> Are you running debian? It likes to nice -10 the X server. Renicing it
> back to 0 fixes my xmms skips with 2.5.

Excellent - that seems to fix it totally. I guess O(1) pays more attention
to nice than 2.4.

> Sean Neakums <sneakums@zork.net> wrote:
>
> You can alter this permanently with 'dpkg-reconfigure xserver-common';
> if you elect not to have /etc/X11/Xwrapper.config managed by debconf,
> simply edit it directly.

Even better ;-)

Thanks,

M.

Re: xmms (audio) skipping in 2.5 (not 2.4)

[Aaron Lehmann]

On Mon, Mar 03, 2003 at 09:25:59PM -0800, Martin J. Bligh wrote:
> So ... is there any easy way I can diagnose this? Does anyone else have a
> similar problem?

I have a very similar problem. Selecting text in a Mathematica window
causes xmms to skip almost always. Sometimes xmms also skips when I
scroll in xft-antialiased mozilla. This never happened in 2.4.

xmms is reading music over NFS.

Re: xmms (audio) skipping in 2.5 (not 2.4)

[Pavel Machek]

Hi!

> > the  "desktop tuning" of making the max timeslice==min timeslice. Try an
> > -mm  kernel with the scheduler tunables patch and try playing with the
> > max  timeslice. Most have found that <=25 will usually stop these skips.
> > The  default max timeslice of 300ms is just too long for the desktop and 
> > interactivity estimator.
> 
> Heh, cool. I have the same patch in my tree too, fixed it without rebooting
> even ;-) Still a *tiny* bit of skipping, but infinitely better than it was.

Fixed without rebooting? You binary-patched
kernel or what?
				Pavel
-- 
				Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...

Re: xmms (audio) skipping in 2.5 (not 2.4)

[Martin J. Bligh]

>> > the  "desktop tuning" of making the max timeslice==min timeslice. Try an
>> > -mm  kernel with the scheduler tunables patch and try playing with the
>> > max  timeslice. Most have found that <=25 will usually stop these skips.
>> > The  default max timeslice of 300ms is just too long for the desktop and 
>> > interactivity estimator.
>> 
>> Heh, cool. I have the same patch in my tree too, fixed it without rebooting
>> even ;-) Still a *tiny* bit of skipping, but infinitely better than it was.
> 
> Fixed without rebooting? You binary-patched
> kernel or what?
> 				Pavel

Nope, the sched tunables patch from Robert (which is in -mjb and -mm, 
so I was already running) exposes those parameters out to userspace 
for sysctl to change ... I just ran sysctl once, and it was done ;-)

M.