bob@ihnss.UUCP (Bob Van Valzah) (05/19/84)
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