On 2003-08-12 14:42:02 gaxt wrote:
[...]
> Galciv plays videos quite smoothly but as soon as I run it it will
> freeze the cursor for 12-15 seconds every half-minute or so even
> within the game itself which is turn-based strategy without a lot of
> whizbang stuff. In the past, the videos would stutter but the game
> would not suffer from more than short pauses now and then.
Similar experience here running the game-test (xfree86 4.3.99.10, winex
3.1 and "Baldurs Gate I") on a PII 400 with 128 meg ram. Using
2.6.0-test3-O14.1int + O14.1-O15int.
I would say this is the best _and_ worst scheduler I've tried since Con
had to adopt his work to the new Ingo infrastructure. Slightly
smoother than pure A3 unless you manage to trigger badness. Then you (or
I, at least) get exactly 15 seconds of total freezes, mixed with
different periods of normality. And by freezes, I mean total freezes.
I can switch to an already opened text console, but there
a running "top" is dead and it won't take any keystrokes until the
freeze has gone. The only thing not dead is the "sound repeats" that
Daniel Phillips explained in:
http://marc.theaimsgroup.com/?l=linux-kernel&m=105966612027670&w=2
--quote--
To convince yourself of this, note that when DMA refill fails to meet
its deadline you will hear repeats, not skipping, because the DMA
hardware on the sound card has been set up to automatically restart the
DMA each time the buffer expires. Try running the kernel under kgdb and
breaking to the monitor while sound is playing.
--unquote--
Mvh
Mats Johannesson
On Wed, 13 Aug 2003 01:23, Voluspa wrote:
> On 2003-08-12 14:42:02 gaxt wrote:
> Similar experience here running the game-test (xfree86 4.3.99.10, winex
> 3.1 and "Baldurs Gate I") on a PII 400 with 128 meg ram. Using
> 2.6.0-test3-O14.1int + O14.1-O15int.
Yes known issue for reason I mentioned. Currently investigating.
> I would say this is the best _and_ worst scheduler I've tried since Con
Can you give us some idea what your machine is like when it's not running a
cpu hog win32 game in wine? Also can you try running your game nice +1
Con
On Wed, 13 Aug 2003 07:15:22 +1000
Con Kolivas wrote:
> On Wed, 13 Aug 2003 01:23, Voluspa wrote:
> > On 2003-08-12 14:42:02 gaxt wrote:
> > Similar experience here running the game-test (xfree86 4.3.99.10,
> > winex 3.1 and "Baldurs Gate I") on a PII 400 with 128 meg ram. Using
> > 2.6.0-test3-O14.1int + O14.1-O15int.
>
> Yes known issue for reason I mentioned. Currently investigating.
Yupp, you posted while I was writing.
> > I would say this is the best _and_ worst scheduler I've tried since
> > Con
>
> Can you give us some idea what your machine is like when it's not
> running a cpu hog win32 game in wine? Also can you try running your
> game nice +1
As I've said, it is extremely hard for me to notice the scheduler unless
I run something graphic intensive, but my comments are of course not
solely based on that game-test. A general feel of smoothness can always
be attributed to the placebo effect, though I challenge anyone to
dispute the following experience.
Fourteen days ago I took home a precompiled Blender 2.28 - previous
copy of this 3D render program to reside here was 2.23. Grabbing the
grid which constitutes the world plane (hold third mouse button, drag)
and rotating it around the axes, I noticed something not present in the
old version. Jerks...
In kernel time this is 2.6.0-test1/2 and Cons O11int. Since then I've
done the "world rotate" on plain kernels and all O-patches without
noticing any improvement. Either mouse pointer or grid gets stuck for
about 1/2 to 2 seconds, making the movement unsynchronized. Can happen
while moving slowly, or spinning like crazy.
I don't have DRI with my mach64 (8 meg) because of choice, use Xv
instead, so I had made up my mind about the blame. Sloppy programming
and weak CPU.
Until O15int enters the mix. Perfect sync all the time, no matter how
slow, fast or long I rotate the world plane. That is why I call this
scheduler the "best". The "worst" part comes from the "known issue" but
also because I happened to run xmms on a directory of mp3s while
rotating. I got severe blackouts in the music, ca 10 - 15 seconds long.
When the blackout starts I no longer have to move the mouse, it is
enough to hold down the button. The second I release it, the music
returns.
Xmms has not been involved in the rotating before, so can't tell if the
blackouts have occurred. Could be due to the "known issue", but I'll
retest with older kernels when time permits.
Running the game-test with nice +1... Well, I tried that first on
wineserver, then wine, then X, after which I put -1 on them
consecutively. No real pattern emerged. Badness all around. And now I'm
falling asleep. Bye.
Mvh
Mats Johannesson