🚀 go-pugleaf

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.edu