2005-11-01 17:18:39

by Patrizio Bassi

[permalink] [raw]
Subject: Re: [BUG 2579] linux 2.6.* sound problems (SOLVED)

Jeffrey Hundstad ha scritto:

> Since you're going to 250 Hz. Please, if you would, see if you can
> tell any performance change and report that as well. I'm more than a
> little skeptical that you'll notice. BTW: Your battery life should be
> a little better at 100 Hz also.
>
sincerely i can notice that task and application switching is a bit slower.
i have a 500mhz cpu so i think i can notice a bit the difference.
i can't estimate it mmm...
i'll say no more that 5-8%.
but i don't know where i'm gaining speed..

however i'm not using battery, this is not laptop so i can't report that.

i'm sorry.


2005-11-01 19:47:35

by Lee Revell

[permalink] [raw]
Subject: Re: [BUG 2579] linux 2.6.* sound problems (SOLVED)

On Tue, 2005-11-01 at 18:18 +0100, Patrizio Bassi wrote:
> Jeffrey Hundstad ha scritto:
>
> > Since you're going to 250 Hz. Please, if you would, see if you can
> > tell any performance change and report that as well. I'm more than a
> > little skeptical that you'll notice. BTW: Your battery life should be
> > a little better at 100 Hz also.
> >
> sincerely i can notice that task and application switching is a bit slower.
> i have a 500mhz cpu so i think i can notice a bit the difference.
> i can't estimate it mmm...
> i'll say no more that 5-8%.
> but i don't know where i'm gaining speed..

Um, wasn't a consensus reached at OLS two years ago that the target for
desktop responsiveness would be 1ms which is impossible with HZ=100 or
250?

Lee

2005-11-01 21:43:46

by Bill Davidsen

[permalink] [raw]
Subject: Re: [BUG 2579] linux 2.6.* sound problems (SOLVED)

Lee Revell wrote:
> On Tue, 2005-11-01 at 18:18 +0100, Patrizio Bassi wrote:
>
>>Jeffrey Hundstad ha scritto:
>>
>>
>>>Since you're going to 250 Hz. Please, if you would, see if you can
>>>tell any performance change and report that as well. I'm more than a
>>>little skeptical that you'll notice. BTW: Your battery life should be
>>>a little better at 100 Hz also.
>>>
>>
>>sincerely i can notice that task and application switching is a bit slower.
>>i have a 500mhz cpu so i think i can notice a bit the difference.
>>i can't estimate it mmm...
>>i'll say no more that 5-8%.
>>but i don't know where i'm gaining speed..
>
>
> Um, wasn't a consensus reached at OLS two years ago that the target for
> desktop responsiveness would be 1ms which is impossible with HZ=100 or
> 250?

Go back and reread the thread in the archives. The short answer is that
he who controls the code controls the decisions. I just fix it
everywhere, since 250 is too fast for optimal battery life, too slow for
optimal response or multimedia, and not optimal for any server
application I run (usenet, dns, mail, http, firewall).

A perfect compromise is one which makes everyone reasonably happy; this
is like the XOR of that, it leaves everyone slightly dissatisfied. ;-)

I'm convinced that Linus choose this value to make everyone slightly
unhappy, so development of various variable rate and tick skipping
projects would continue. Unfortunately that doesn't seem to have
happened :-(

--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me

2005-11-01 23:28:27

by Kyle Moffett

[permalink] [raw]
Subject: Re: [BUG 2579] linux 2.6.* sound problems (SOLVED)

On Nov 1, 2005, at 16:44:42, Bill Davidsen wrote:
> Go back and reread the thread in the archives. The short answer is
> that he who controls the code controls the decisions. I just fix it
> everywhere, since 250 is too fast for optimal battery life, too
> slow for optimal response or multimedia, and not optimal for any
> server application I run (usenet, dns, mail, http, firewall).
>
> A perfect compromise is one which makes everyone reasonably happy;
> this is like the XOR of that, it leaves everyone slightly
> dissatisfied. ;-)
>
> I'm convinced that Linus choose this value to make everyone
> slightly unhappy, so development of various variable rate and tick
> skipping projects would continue. Unfortunately that doesn't seem
> to have happened :-(

No, I think it's been happening, it's just that said developers are
still fixing the copious bugs in the various kernel concepts of
"time". IIRC John Stultz' rework is approaching completion, and when
that goes in it makes life a lot easier for the various dyntick and
variable tick projects.

Cheers,
Kyle Moffett

--
Unix was not designed to stop people from doing stupid things,
because that would also stop them from doing clever things.
-- Doug Gwyn