peter@hydrovax.nmt.edu (Peter A. Blemel) (12/05/89)
Hi All,
Here's the follow up to my Interleaf death-program-from-hell problem:
I got a fix from IBM on a disk with a hand-typed instruction sheet and
hand written label. IBM said, "It hasn't been tested..." I believe them.
It is an 'hft' fix (whatever that means) that comes with install and
un-install shell scripts. It get's installed in /usr/sys.
What it does: It uses archive (ar) to replace a module in one of the
lib files in /usr/sys. Before it does, it makes a copy (so un-install
can get it back) of the .a file in question. It then re-links the kernel.
It makes a copy of the old unix and moves unix.std to / for you. It then
tells you to reboot.
What it does not do: IBM said it would allow me to change the priority
of any VRM type program. This is not true. I can nice all I want and
'ps' still shows the same nice (10) and prio (29) for interleaf. At first I
thought the fix failed, but I did not un-install (I thought maybe 'renice'
was in order, but I don't think there's any such beast. Anyway I called
IBM and asked just in case there was.). Later, while working at my
terminal I heard typing at the console, but hadn't experienced the
usual funeral march. I trudged around the corner, and lo and behold, the
system isn't killed by interleaf any more. In fact, it responds fairly well
now.
What I think it does: Near as I can tell, what it does is keeps ANY
vrm/monitor mode program from running at elevated priority inside/on
(or however it works) the VRM. I draw this conclusion from the following:
When in XWindows: Executing any command that keeps a window busy (for
example ls -l in /usr/lpp/tps4.0/fonts) results in extremely choppy cursor
movement when the mouse is moved (in fact, it can be as bad as 1 second from
the time you move the mouse until the cursor catches up.) This is definately
new behavior. It must not deal with interupts well.
When in PCSIM: Most screen oriented functions (pc applications) are
significantly slower. The console mouse doesn't work inside the simulator,
but screen refreshes are choppy. I am usually only editing, but the Megapel
(even with the cga switch set) does font conversion. I don't use this
much, so It doesn't bother me as much as the X slowdown.
What I learned: All things considered, the patch is acceptable. The system
remains smooth when interleaf is running, thereby solving my biggest headache.
I can live with X and pcsim performance hits (unless the screen is really
busy it's not really noticable anyway). I am usually only compiling and running
math based test cases in an average day, but the system seems about the
same speed for those. I don't thrash memory much so I can't say if any
pagefile or memory stuff has slowed down.
Something else I learned: I got to play a lot with /etc/master through
all of this. Before the patch I spent a lot of time trying to get performance
back by tweaking the kernel. Since I was desperate, I tried some radical
changes (none of which helped when interleaf ran) that *really* increased
the performance of the system when under normal (4-6 users compiling, editing,
and the like) load. The parameters (default) in there are for an average sort
of machine. They have an autogen sort of thing that configures for <2.0mb or
>2.0mb depending on memory at boot time if you leave it at the default
value of 0. I figured, well 16mb is a lot more than two, so I made it
a big number. I wasn't expecting to write this paragraph, so I don't have
the exact parameter name/number - but if you look under master in the
manual, you can find it. Just about everything marked on that page as
'user changeable' got changed. For the most part I heeded the manual's
warnings about exorbitant values wasting memory. I left the time slice at
default (20 I think), but I bumped all the hash and cache type entries up. It
really made quite a difference in the overall performance of the machine.
Oh, and I replaced the "AIX Version" string with a cute message.
Well, there it is. Sorry it's so choppy, but it's sort of finals week/last
week of classes and I haven't been sleeping much. Hope it helps someone.
I really appriciate all the feedback I got from you folks through all of
this. Once the problem was narrowed down, the fix was right behind it. Too
bad IBM doesn't warn you about these things (or even know about them when
you call to ask).
Thanks again,
Peter
-----
peter@hydrovax.nmt.edu
peter@amber.nmt.edumoody@moody.UUCP (moody) (12/06/89)
In article <3603@nmtsun.nmt.edu>, peter@hydrovax.nmt.edu (Peter A. Blemel) writes: > > Here's the follow up to my Interleaf death-program-from-hell problem: > [explanation of update deleted] > What it does not do: IBM said it would allow me to change the priority > of any VRM type program. This is not true. That is correct. One cannot change the priority of VRM programs. > 'ps' still shows the same nice (10) and prio (29) for interleaf. At first I > thought the fix failed,..... 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. You and some other customers don't like the new behavior. The 'patch' you received removes this change which causes the rescheduling. The slower mouse tracking is the result of the interleaf process no longer being rescheduled. [more stuff deleted for bandwidth's sake] disclaimer: I work for IBM and I know about this change. I am not an official spokesperson for IBM. -- James Moody Adv Workstation Div IBM Austin, 2502 aesnet: moody@moody.austin.ibm.com vnet: MOODY at AUSVM6 outside -> ...!cs.utexas.edu!ibmaus!auschs!moody.austin.ibm.com!moody
peter@hydrovax.nmt.edu (Peter A. Blemel) (12/06/89)
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