Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde!uunet!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!unmvax!nmtsun!peter@hydrovax.nmt.edu
From: peter@hydrovax.nmt.edu (Peter A. Blemel)
Newsgroups: comp.sys.ibm.pc.rt
Subject: Re: Kernel patch for AIX2.2.1 (priority problem)
Message-ID: <3607@nmtsun.nmt.edu>
Date: 5 Dec 89 23:03:01 GMT
Sender: news@nmtsun.nmt.edu
Organization: New Mexico Tech Hydrology Program
Lines: 44

In article <2852@moody.UUCP>, moody@moody.UUCP (moody) writes...
>In article <3603@nmtsun.nmt.edu>, peter@hydrovax.nmt.edu (Peter A. Blemel) writes:
>> 
>>    Here's the follow up to my Interleaf (moody explative) problem:
>> ... 
>I believe that at some point, IBM had a customer problem with the tracking of
>the mouse.  The latest version of AIX fixed that problem by always giving the
>process running in monitored mode the highest possible scheduling values (cpu,
>and priority) whenever the mouse generated an interrupt.  That is, whenever
>your interleaf user moved the mouse, that process was rescheduled in effect.
>This causes other processes to be starved if the mouse is being moved a lot.  

Actually, the times when the system was affected worst (before the fix) was
when the secretary (or any fast typist) was rapidly typing away and not really
using the mouse. When I was trying to isolate the problem we tried a lot
of different usage combinations (I.e. moving the mouse, saving files, etc)
and rapid typing was definately the worst.

>You and some other customers don't like the new behavior.  The 'patch' you
>received removes this change which causes the rescheduling.

As a side point: I personally think it's a bad idea to give processes running
on the console that kind of devestating priority change when the system
is supposed to be multi-user / multi-tasking. Network response was drastically
affected as was general user response. The system was basically reduced to a
PC type single user machine, only it's a lot more expensive. It's my guess
that the AIX hack was to make the system performance look smooth when IBM is
trying to sell the things.

> The slower mouse
>tracking is the result of the interleaf process no longer being rescheduled.
>...

Interleaf performs at about the same speed it used to, and it does not
experience the poor mouse tracking. It's only in X when there's a lot of
screen activity going on.

Thanks for your post. For as much griping as I'm doing (this was a VERY
annoying problem) I appriciate learning more about the way AIX does things.

Peter
-----
peter@hydrovax.nmt.edu
peter@amber.nmt.edu