mp@allegra.UUCP (Mark Plotnick) (12/07/86)
We'd like to put Fujitsu 2361 super-eagles on our VAX 8650's. The company selling and installing them would like us to use Emulex SC7003 controllers, since we can use them first on a little-used 750 to format the drives and then on the 8650's. The 4.3BSD hp drivers want to use 64 sectors/track (does anyone know why they don't use 68?), and the SC7003 only provides RM05 emulations for the 2361 in the 64 sector configuration. the hpmaptype() routines only handle alternate RM02 emulations, though. While the changes to make the drivers handle alternate RM05 emulations don't seem hard (we've done it for the CDC 9771), I'm wondering what other people have done. We could just ask to use SC7002's, which do offer an 842x20x64 RM02 emulation. Also, everyone we've talked to thinks there's a limit of 2 Emulex massbus controllers per system, and a practical limit of 4 drives per controller. If this is true, what should we do when we need to expand? Use other vendors' massbus controllers, or add some unibus controllers? (for the latter, we know that UDA50's and RA81's exist - in fact, they're the reason we're switching to Emulex/Fujitsu.) Mark Plotnick allegra!mp
mangler@cit-vax.Caltech.Edu (System Mangler) (12/07/86)
In article <6387@allegra.UUCP>, mp@allegra.UUCP (Mark Plotnick) writes: > the SC7003 only provides RM05 emulations for the 2361 in the 64 sector > configuration. the hpmaptype() routines only handle alternate RM02 > emulations, though. Use of the RM02 drive type is historical; Berkeley requested it. It is useless to VMS sites (who make up the bulk of Emulex's business), because all they can patch in DRDRIVER is the geometry table for some drive type that DRDRIVER already knows about. In recent versions of VMS, that must be one of RM03, RM05, RM80, or RP07, so emulations had better identify themselves as one of those. The problem is that hpmaptype() is trying to key off of the drive type to see if it's "safe" to poke the holding register. I think this isn't necessary. The holding register doesn't do anything useful, so it can't hurt to poke random values into it, and if the controller isn't Emulex, it should give you back whatever you poked it with (or at worst, zero), which you sure won't find in your geometry table. If you're paranoid you might clear hpdc first. So, for 4.3bsd, you want to move the RM02 differentiation code up ahead of the SI check, and simply get rid of the insistence that it be an RM02. > Also, everyone we've talked to thinks there's a limit of 2 Emulex > massbus controllers per system, and a practical limit of 4 drives per > controller. Probably the limits of Ultrix. Also, a Vmaster (CMI/SBI converter) will only hold two controllers. Do be sure to use short "A" cables if you intend to daisy-chain lots of drives, the total must be less than 100 feet. The sector search "optimization" code, which is even more wrong in 4.3bsd, will degrade throughput when several drives are active on one controller. Set sc->sc_doseeks to disable this suboptimization. Making it work correctly would require more cooperation between the hp driver and the mba code, and isn't worth it. Don Speck speck@vlsi.caltech.edu {seismo,rutgers,ames}!cit-vax!speck
jc@piaget.UUCP (12/10/86)
In article <6387@allegra.UUCP> mp@allegra.UUCP (Mark Plotnick) writes:
->We'd like to put Fujitsu 2361 super-eagles on our VAX 8650's. The
->company selling and installing them would like us to use Emulex
->SC7003 controllers, since we can use them first on a little-used 750 to
->format the drives and then on the 8650's.
-> ...
->Also, everyone we've talked to thinks there's a limit of 2 Emulex
->massbus controllers per system, and a practical limit of 4 drives per
->controller. If this is true, what should we do when we need to
->expand? Use other vendors' massbus controllers, or add some unibus
->controllers? (for the latter, we know that UDA50's and RA81's exist -
->in fact, they're the reason we're switching to Emulex/Fujitsu.)
->
Using Emulex V-Master systems you can have exactly twice the
number of _Mass_Busses_ allowed by DEC in the same physical
space. As I recall the configuration of the 8650, Emulex hangs a
half width cabinet onto the system which holds up to 2 V-Masters.
Each V-Master holds 2 controllers. Each controller holds 4
drives. Consequently the maximum number of drives would be 16
for an insignificant 9.6 Gigabytes of on line storage.
Concerning the mapping for the 2361, may I suggest that you write
down the configuration you would like to have and call Emulex
customer service. They will tell you how to get the non standard
emulation. It costs somewhere between $75 and $150 and your
local Emulex reseller will probably mark it up. Even at that,
it's cheap at twice the price if you can get what you want. All
they do is burn a new configuration prom (which you may then
order on all subsequent controllers). The only caveat I can
think of is if there is some buffer size or register limitation
on the number of sectors per cylinder.
--
John Cornelius
(...!sdcsvax!piaget!jc)chris@mimsy.UUCP (Chris Torek) (12/31/86)
In article <1305@cit-vax.Caltech.Edu> mangler@cit-vax.Caltech.Edu (System Mangler) writes: >... hpmaptype() is trying to key off of the drive type to see if >it's "safe" to poke the holding register. I think this isn't necessary. If anyone knows otherwise, let us know. I was just bitten by this. We put a fifth Eagle drive on an SC788 controller, and could not get drive four to show up as an Eagle. Switching the drive numbers on 3 and 4 showed that the drive itself was configured properly. It turned out that the last person to fool with the 788 configuration had left the switches in `4 RM02, 4 RM05' mode, instead of `8 RM02' mode. I would rather have the software figure out the hardware configuration in spite of the switch settings. >The sector search "optimization" code, which is even more wrong in >4.3bsd, will degrade throughput when several drives are active on >one controller. ... Making it work correctly would require more >cooperation between the hp driver and the mba code, and isn't worth it. Why not? -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) UUCP: seismo!mimsy!chris ARPA/CSNet: chris@mimsy.umd.edu
mangler@cit-vax.Caltech.Edu (System Mangler) (01/04/87)
In article <1305@cit-vax.Caltech.Edu> I write: > The sector search "optimization" code, which is even more wrong in > 4.3bsd, will degrade throughput when several drives are active on > one controller. ... Making it work correctly would require more > cooperation between the hp driver and the mba code, and isn't worth it. In article <4892@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) asks: > Why not? The object of sector searching is to avoid tying up the controller with disk rotational latency. It only gains something if another drive is ready to do a transfer immediately. This is an unlikely event on a low-end VAX, which doesn't have enough CPU power to keep a Massbus controller that busy, and which can ill afford the additional interrupts. For sector searching to work properly, the disk has to repeat the search until it finds the controller ready to transfer immediately. If it were to quit after one search (like in 4.3 BSD), it gets put in a FIFO queue, the same as if it hadn't searched at all. My first attempt at a rewrite did not quit after one search; it searched forever, because it depended on the mindist/sdist/maxdist numbers being sane, and they weren't. 4.3 BSD has all the sdist and maxdist numbers interchanged. That is the great weakness of sector searching: it requires tuning numbers, and obviously, nobody cares about it enough to even make sure the numbers are in the right order! If it's not going to be done right, why do it at all? Don Speck speck@vlsi.caltech.edu {seismo,rutgers,ames}!cit-vax!speck
mat@amdahl.UUCP (Mike Taylor) (01/05/87)
In article <1421@cit-vax.Caltech.Edu>, mangler@cit-vax.Caltech.Edu (System Mangler) writes: > > The object of sector searching is to avoid tying up the controller > with disk rotational latency. It only gains something if another > drive is ready to do a transfer immediately. This is an unlikely > event on a low-end VAX, which doesn't have enough CPU power to > keep a Massbus controller that busy, and which can ill afford the > additional interrupts. > Sector searching was introduced (as far as I know - there may have been prior art) by IBM with the 3330 DASD in about 1970, called Rotational Position Sensing. The idea was to optimize the use of S/370 channels, rather than control units. It worked OK, but now has been enhanced to allow the reconnecting controller to select among multiple attached channels, thus improving the chances of a free channel being found when needed. Since multiple controllers will normally be attached to a channel, the controller is generally not as scarce a resource. -- Mike Taylor ...!{ihnp4,hplabs,amd,sun}!amdahl!mat [ This may not reflect my opinion, let alone anyone else's. ]