Here is an evolution of the O1int design to minimise audio skips/smooth X.
I've been forced to work with even less sleep than usual because of this but
I'm getting quite happy with it now.
Changes:
Reintroduction of the child penalty set at 95, but normalised to work for a 2
second average to work with the new system.
Long sleepers classified as idle again like previous incarnations instead of
being reset, but over a 2 second average.
This should impact on a lot of the corner cases.
More thrashing please. I know these had been coming out frequently but I
needed to assess every small increment. I hope not to need to do too much
from here.
Con
On Tue, 1 Jul 2003 09:44, Con Kolivas wrote:
> Here is an evolution of the O1int design to minimise audio skips/smooth X.
> I've been forced to work with even less sleep than usual because of this
> but I'm getting quite happy with it now.
>
> Changes:
> Reintroduction of the child penalty set at 95, but normalised to work for a
> 2 second average to work with the new system.
> Long sleepers classified as idle again like previous incarnations instead
> of being reset, but over a 2 second average.
>
> This should impact on a lot of the corner cases.
>
> More thrashing please. I know these had been coming out frequently but I
> needed to assess every small increment. I hope not to need to do too much
> from here.
The sleep thing is definitely affecting me.
Here is a small bugfix.
On Tue, 1 Jul 2003 09:44, Con Kolivas wrote:
> Here is an evolution of the O1int design to minimise audio skips/smooth X.
> I've been forced to work with even less sleep than usual because of this
> but I'm getting quite happy with it now.
[snip]
> More thrashing please. I know these had been coming out frequently but I
> needed to assess every small increment. I hope not to need to do too much
> from here.
Well, this doesn't quite work. It initially seemed to prevent audio
skips, but now I can't launch a new Eterm (with translucency) with the
music not skipping, no change from stock -mm. It seems to work better
under heavy load (extracting a chroot tarball for example) than when
nothing is happening, which kind of puzzles me. In both cases I launch
a new Eterm while music is playing.
Inexplicably, it sometimes prevents skipping entirely.
I'm on a P4 2.0GHz with 256MB of SDRAM.
Regards
Josh
--
A man may be so much of everything that he is nothing of anything.
-- Samuel Johnson
On Mon, Jun 30, 2003 at 06:04:13PM -0700, Joshua Kwan wrote:
> Well, this doesn't quite work.
It seemed to help GTK2 applications. Used to be that in Firebird, I
would get a skip when a page was rendering - it seems to be gone.
Just a small addendum :)
-Josh
--
A man may be so much of everything that he is nothing of anything.
-- Samuel Johnson
On Tue, 1 Jul 2003 11:04, Joshua Kwan wrote:
> On Tue, 1 Jul 2003 09:44, Con Kolivas wrote:
> > Here is an evolution of the O1int design to minimise audio skips/smooth
> > X. I've been forced to work with even less sleep than usual because of
> > this but I'm getting quite happy with it now.
>
> [snip]
>
> > More thrashing please. I know these had been coming out frequently but I
> > needed to assess every small increment. I hope not to need to do too much
> > from here.
>
> Well, this doesn't quite work. It initially seemed to prevent audio
> skips, but now I can't launch a new Eterm (with translucency) with the
> music not skipping, no change from stock -mm. It seems to work better
> under heavy load (extracting a chroot tarball for example) than when
> nothing is happening, which kind of puzzles me. In both cases I launch
> a new Eterm while music is playing.
>
> Inexplicably, it sometimes prevents skipping entirely.
Well we're on the way. Sing with me... a tweaking we will go..
Here is a tweaked patch with small changes otherwise which should help.
P.S. Were you running 100Hz?
Con
On Tue, Jul 01, 2003 at 12:10:31PM +1000, Con Kolivas wrote:
> Well we're on the way. Sing with me... a tweaking we will go..
> Here is a tweaked patch with small changes otherwise which should help.
>
> P.S. Were you running 100Hz?
> Con
Yes, and with this patch coupled with reversing andrew's 100hz patch,
makes the skips largely disappear.
Or could it be that 1000hz alone fixes everything? Who knows...
-Josh
--
A man may be so much of everything that he is nothing of anything.
-- Samuel Johnson
On Tue, 1 Jul 2003 14:41, Joshua Kwan wrote:
> On Tue, Jul 01, 2003 at 12:10:31PM +1000, Con Kolivas wrote:
> > Well we're on the way. Sing with me... a tweaking we will go..
> > Here is a tweaked patch with small changes otherwise which should help.
> >
> > P.S. Were you running 100Hz?
> > Con
>
> Yes, and with this patch coupled with reversing andrew's 100hz patch,
> makes the skips largely disappear.
>
> Or could it be that 1000hz alone fixes everything? Who knows...
Great thanks. I'll try my best to leave it alone for a while now and let
others test it (no 1000Hz alone does not fix this problem).
I'll leave the latest available O1int patch here:
http://kernel.kolivas.org/2.5
for downloading and remind people that if you use the -mm tree you will see
better performance if you reverse patch the 100Hz patch, but it still should
benefit at 100Hz.
Con
Hello,
On Tue, Jul 01, 2003 at 09:52:26AM +1000, Con Kolivas wrote:
> On Tue, 1 Jul 2003 09:44, Con Kolivas wrote:
> > Here is an evolution of the O1int design to minimise audio skips/smooth X.
> > I've been forced to work with even less sleep than usual because of this
> > but I'm getting quite happy with it now.
for normale usage I'm happy with it, even under heavy load (two kernel
compiles with -j4 on a single processor machine) I can type into my
xterms mostly instantly.
However starting new applications/xterm's is a pain, a plain xterm which
starts normally within a second takes about 3-5secs. Openoffice isn't
usable at all. But on the other side I normally don't compile with
-j4...
However the xmms didn't skip once while playing. I applied this patch
ontop of 2.5.73-bk7.
--
Regards,
Wiktor Wodecki
On Tue, 1 Jul 2003 20:12, Wiktor Wodecki wrote:
> Hello,
>
> On Tue, Jul 01, 2003 at 09:52:26AM +1000, Con Kolivas wrote:
> > On Tue, 1 Jul 2003 09:44, Con Kolivas wrote:
> > > Here is an evolution of the O1int design to minimise audio skips/smooth
> > > X. I've been forced to work with even less sleep than usual because of
> > > this but I'm getting quite happy with it now.
>
> for normale usage I'm happy with it, even under heavy load (two kernel
> compiles with -j4 on a single processor machine) I can type into my
> xterms mostly instantly.
> However starting new applications/xterm's is a pain, a plain xterm which
> starts normally within a second takes about 3-5secs. Openoffice isn't
> usable at all. But on the other side I normally don't compile with
> -j4...
> However the xmms didn't skip once while playing. I applied this patch
> ontop of 2.5.73-bk7.
At least we're moving in the right direction; last time you tried it was a
disaster on your machine. Tuning can help this sort of thing. Before I tweak
it further to tackle this can you tell me exactly which version you used?
Sorry it's such a moving target.
Con
Con, I want to give you Lots of Thanks for the work you're doing with the O1int patches.
Don't you think that we need an option in the kernel to select if we want a Server Kernel or a Desktop Kernel?
With the first one, only throughput is important and in the second one, we can take in all the stuff to improve the interactivity (preempt, 01int, granularity) so we can give more agresive interactivity to the Desktop Kernel.
Is this a sillyness?
--
=============================================================
Luis Miguel Garcia Mancebo
Ingenieria Tecnica en Informatica de Gestion
Universidad de Deusto / University of Deusto
Bilbao / Spain
=============================================================
On Tue, 1 Jul 2003 21:32, Luis Miguel Garcia wrote:
> Con, I want to give you Lots of Thanks for the work you're doing with the
> O1int patches.
Thanks. Hopefully it will all be worthwhile.
> Don't you think that we need an option in the kernel to select if we want a
> Server Kernel or a Desktop Kernel?
>
> With the first one, only throughput is important and in the second one, we
> can take in all the stuff to improve the interactivity (preempt, 01int,
> granularity) so we can give more agresive interactivity to the Desktop
> Kernel.
A properly tuned scheduler should work in all settings. The granularity patch
is the only one which would only benefit the desktop but I'm hoping to make
it unnecessary for this patch to be used.
Con
On Tue, Jul 01, 2003 at 01:32:41PM +0200, Luis Miguel Garcia wrote:
> With the first one, only throughput is important and in the second one, we can take in all the stuff to improve the interactivity (preempt, 01int, granularity) so we can give more agresive interactivity to the Desktop Kernel.
>
> Is this a sillyness?
placing this in /proc would be a better idea. The more I watch the whole
interactivity debate I think that there is no golden way for server and
desktop machines.
--
Regards,
Wiktor Wodecki
On Tue, 1 Jul 2003 12:51:57 +0200
Wiktor Wodecki <[email protected]> wrote:
> On Tue, Jul 01, 2003 at 01:32:41PM +0200, Luis Miguel Garcia wrote:
> > With the first one, only throughput is important and in the second one, we can take in all the stuff to improve the interactivity (preempt, 01int, granularity) so we can give more agresive interactivity to the Desktop Kernel.
> >
> > Is this a sillyness?
>
> placing this in /proc would be a better idea. The more I watch the whole
> interactivity debate I think that there is no golden way for server and desktop machines.
This is for what I have said that. Sometimes the people says. "This is good for Desktop, but drops the performance / throughput 20%". Perhaps some people prefer having a true multimedia desktop without skips in the music and video, and less throughput (like i prefer).
But let Con do it's best. I think he knows what is doing ;)
Thanks Con and others!