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 ;-)
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
>> 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.
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
>> >> 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.
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
> 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.
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 <[email protected]>
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
>
> 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
> 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
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.
[|] <[email protected]> | That's why I use Emacs.
\ |
> Per chance, do you have an NVidia graphics card and Maestro 3 or USB
> audio?
Neither ...
M.
> 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 <[email protected]> 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.
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.
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...
>> > 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.