SCO Xenix 386 and VP/ix

[Dave Remien]

In article <162 at mdi386.UUCP> bruce at mdi386.UUCP (Bruce A. McIntyre) writes:
+>First of all, you CAN run VP/IX from terminals, and the vt100nam is supported.
+>They also support wy60 and some others.  However, you need to allocate at
+>least 1MB of ram for every user of VP/IX, not including xenix kernal, etc.
+>This means to do 4-5 users, I would recommend 8 megs minimum.  If you want
+>to use VP/IX, remember that disk I/O will be quite rapid, but compute
+>intensive tasks will seem to take forever.  For instance, I have a flow
+>chart program that works just fine for creating the charts, but when trying
+>to print, the computations to build the image for the laserjet seems to take
+>forever.  There is a lot of polling going on from DOS as well, and it eats
+>up a lot of processor time.. My suggestion is to only keep a couple of VP/IX
+>sessions active at any one time.  However, I am running on a 16MHZ386 box,
+>so you might get lucky on a 33MHZ386 box.  Terminals can only run one session
+>of VP/IX as far as I know.

I haven't tried this; it would depend on whether VP/IX takes over ^Z,
but would shell layers (shl) allow multiple sessions? Not that one would
want to. 

When VP/IX goes into slo-mo territory (anything that starts output to
the printer goes into near catatonia), the only solution I've found is to
make the kernel context switch more often. One of the tunable parameters
(mtune?) is MAXSLICE, which is the time slice in HZ given to a process.
While it defaults to 100, and for V/386 3.2 has upper and lower limits
of 100, you can set the lower limit down, and set the value of MAXSLICE
to 15 or 20. (Then rebuild the kernel, of course). For me, this cut the
time for a program to do a screen dump (EGA) and send it to an HP
Paintjet from 8 to 10 minutes under VP/IX down to 2.5 minutes.

At least DOS-Merge has the fast clock option, which eliminates this
behavior.  Not to mention timeoutable flushing of the print queue,
though I understand that the latest version of VP/IX doesn't need the
doscmd flush barf. 

Note that switching MAXSLICE to a smaller value causes the kernel to
spend more CPU time on playing with the run queue, but for us, it was
the only way to get VP/IX to do anything in less than a year or so.
-- 
Dave Remien - WINCO Computer Eng. Group -{uunet | bigtex}!pmafire!dave- 
I certainly, absolutely, positively, don't speak for Westinghouse. And I
don't think I want to.			"Dave Barry for President"