MicroVAX II performance?

jqj at cornell.UUCP jqj at cornell.UUCP
Tue May 21 19:55:28 AEST 1985


From: jqj (J Q Johnson)

To reiterate a request that has already appeared on Unix Wizards, can
anyone out there provide information on MicroVAX II performance with
multiple users under Unix?  Granted, the MV II is a fast, nifty machine
for a small number (1 to 3?) of users; can it replace a 780 (750?)
for ordinary timesharing?  It certainly won't replace my 780 with
2GB of disk and 40 to 50 users (at least not this year), but how would
it perform in a configuration with, say, 5MB memory, 5 RD53 disks,
and 12 simultaneous timesharing users?

Some issues:

	The RD53 is a fairly slow disk (RD52 is too slow to
even consider in this context).  The controller for A-series disks
won't be available till late this year (or, more likely, early next
year).  Will lots of spindles make up for slower average access?
Let's ignore the issue of whether 350MB is enough disk and simply
worry about performance for a while.

	The MV II uses the Q bus for all I/O.  Is this a potential
bottleneck, particularly in an environment with moderately high
Ethernet traffic competing for the bus?  My experience with 780s
seems to be that they are very happy to have their disks sitting on 
Massbus or SI controllers (or on a CI).  If I were configuring a
780 with UDA-50, I think I'd want to hang it on a dedicated Unibus.
Can I install a second Q bus on the MV II?

	How smart is the controller for the RD53?  In a typical
disk transfer, how much work does the CPU have to do compared, for 
example, to a UDA50?

	How wide is the DMA path from Qbus to memory?  Unless memory
deceives me, the VAX/750 has only 4 registers for controlling byte
DMA transfers, which makes them a very scarce resource, especially if
for speed your drivers want to dedicate one or two to each DMA device;
780 has 64, which is plenty.  How many has the MV II?

	How big is the cache, and how fast is main memory?

	Floating point performance:  I gather that the MV II supports
G and H format fp numbers.  How about D format?  In hardware or in
emulation?  How fast?  Note that binaries from existing C programs will
do all their calculations in D format, so if D format is slow one would
at least want to recompile using a compiler that generates G format;
what does the distributed Ultrix C compiler use?

	What other potential bottlenecks exist in the MV II architecture?



More information about the Comp.unix.wizards mailing list