CPU overhead of X on a VAXstation II?

[Jim Gettys]

In article <902 at harvard.UUCP> dyer at harvard.UUCP (Steve Dyer) writes:
>Does anyone have any hard figures on the CPU overhead of running "X"
>on a VAXstation II which is also planned to be used as a general-purpose
>time-sharing machine?  Anecdotally, I've been playing with one, and with
>one or two additional jobs running on other terminals, I can see the
>time-slicing during window-scrolling.  It's a new experience getting
>swapped out in the middle of drawing a character or redrawing half a line! 

The VS-2 and VS-2/RC (VAXstation II) uses the QVSS display, which is
memory on the Q-Bus.  There is NO hardware assist.  When scrolling or
painting text, therefore, the CPU is compute bound manipulating display
memory.  X is a user level process, and so will be timeshared like any
other process.  This means that in a timeshared environment, the window
system will slow down in direct proportion to the timesharing (causing
the pauses in the middle of character painting when some other process
is running).  If you are actually swapping, you need more memory in
your machine.

If you want to give preference to the user of the display, and don't
care about penalizing other users on the machine, you can simply up the
priority on the window system server.  The moral here is that the VS-2
is intended to be used as a single user workstation.

Displays with outboard processing power (for example, the DEC VS100 on
unibus Vaxes) do much better in a timeshared environment.  We have run X
on as many as four of them on a single VAX 11/750 here without much
problem.  (Of course, a time shared 11/750 is much less useful than a
microVAX.)  A VAXstation II/GPX might also be more viable in this
situation, though we have not run any in this fashion at MIT (my GPX is
ALL MINE, thank you! :-) ).
				Jim Gettys
				Digital Equipment Corporation
				MIT Project Athena