RP07-d with 4.2bsd

Bob Van Valzah bob at ihnss.UUCP
Sat May 19 08:01:47 AEST 1984


People running 4.2bsd on RP07's should be aware of the performance
difference the RP07-d option can make.  With this option, I've
measured I/O rates from user mode of over 700 Kbytes/sec.  Before I got
the -d option turned on, I couldn't get over 360 Kbytes/sec (about the
same as with my beat up old RP06's).

The difference is that with the RP07-d option, the surface of the disk
is formatted with the sectors in sequential order around the
circumference, hence an entire track can be read in one revolution.
Without the option, the sectors are 2 to 1 interleaved and it takes two
revolutions to read an entire track.

To get the RP07-d option working, you need many things:

	1) interleaved memory to handle the higher I/O rates,
	2) an ECO for the RP07 to handle the faster data clock,
	3) an ECO to your RH780 (massbus adapter) for a larger silo,
	4) a jumper set inside the RP07 to enable the faster clock,
	5) the surface of the RP07 has to be reformatted for
	   non-interleaved sectors.

Anyone who thinks they already have the RP07-d option should run the
benchmarks given in "Performance Effects of Disk Subsystem Choices for
VAX Systems Running 4.2BSD UNIX" (see /usr/doc/diskperf).  I thought
our VAX had this option because it said it did on the purchase order (I
got here after the VAX).  It turned out that our VAX had been installed
with the option, but that DEC had turned it off because it was causing
disk errors.  Nobody around here remembers DEC telling us that they'd
turned it off.

I've since found out that DEC knew about the errors and, until
recently, had the RP07-d on "engineering hold."  Within the last month,
they've completed an ECO to the RH780 that allowed the RP07's to run at
full speed.  When I installed 4.2 and found that my RP06's and RP07's
ran at the same speed I complained to DEC and they then installed
RH780's with the new ECO and reformatted my RP07's.

Before considering this upgrade, be warned that the increased transfer
rate will probably aggravate any latent problems in your massbus.  It
took our DECmen about 8 hours to get the massbus working again after
speeding up the RP07's.

After all was said and done, our RP07's perform very well indeed.
Using the benchmarks given in the paper referenced above, they just
slightly outperform the Emulex SC780/Fujitsu Eagle combination.  Here
are the I/O rates I measured, along with those of the Emulex for
comparison:

	Logically sequential transfers from an 8K/1K 4.2bsd file
	system in Kbytes/sec (CPU usage in parenthesis)

	Test		RP07-d		Emulex/Eagle
	====		======		============
	read_8192	680 (81%)	560 (70%)
	write_4096	480 (96%)	440 (98%)
	write_8192	590 (97%)	490 (98%)
	rewrite_8192	770 (96%)	760 (100%)

	Logically sequential transfers from an 4K/1K 4.2bsd file
	system in Kbytes/sec (CPU usage in parenthesis)

	Test		RP07-d		Emulex/Eagle
	====		======		============
	read_8192	460 (69%)	490 (77%)
	write_4096	410 (97%)	380 (98%)
	write_8192	430 (97%)	380 (99%)
	rewrite_8192	510 (93%)	490 (87%)

I didn't do any two drive tests, but I'd like to hear from anyone who
does them.  I'd also like to hear from anyone who has run these
benchmarks on the UDA50/RA81 combination, as we have a couple of these
drives comming in and the paper doesn't give reliable measurements for
these drives.

	Bob Van Valzah
	Consultant to AT&T Bell Labs  (312) 979-3632  ..ihnp4!ihesa!bob
	Employed by   Lachman Assoc.  (312) 986-8840  ..ihnp4!laidbak!bob



More information about the Comp.unix.wizards mailing list