DPT Raid Controller
For an overview of RAID, see Raid Definitions.
DPT ( http://www.dpt.com) builds a complete line of SCSI raid controllers. This review is of the PM3334UW Smart Raid IV (note: even at the time this was written, DPT had already announced a new generation of SmartRaid V conrollers).
The controller was installed in a clone box using an Asus motherboard with a 350 MHZ Pentium II, 128 MB memory, and 4 (four) IBM DDRS 34560 SCSI (40 MB/second) drives. The controller itself was configured with 8 MB of cache memory.
The physical configuration of the machine was done by the customer's Windows hardware supplier. These kinds of suppliers usually don't understand SCSI at all, so I didn't expect much. In this particular case they came close: they terminated the right drive, and only one drive, and actually even understood that an external DAT tape drive meant that the controller needed to be set for HIGH termination only. They even took the trouble to label each drive with what they thought the SCSI ID's would be; unfortunately that was all completely wrong because these drives use 4 bit addresses, and what they thought was a spare jumper is actually the jumper that controls the high (ID 8-15) addresses. Further, none of the drives had id 0, so that isn't a good setup under normal conditions.Still, I've had Windows vars do much worse, so I didn't complain.
They didn't even attempt to configure the array, explaining that they had no knowledge of such things and that I'd probably want to set it up "my way" anyway. Fine by me.
The DPT board comes with a pretty good manual. I've installed a few of these in the past, so I just gave it a quick look to see if anything had seriously changed, and it hadn't. The first thing you need is a bootable floppy disk. After booting with that, you can use the DPT DOS installation disk to configure the array.
The first thing it asks is if you want to make OS installation disks. Of course you do, and it brings up a colorful display of the various OS's it supports, which of course includes SCO, Linux, NT and just about everything else. For SCO, you are creating a BTLD that will be used later.
After creating the specific OS disks, it's time to configure the array. I forgot to make the floppy disk know anything about mice, so I couldn't take advantage of the full GUI nature of the array configuration utility, but using it without a mouse is fairly intuitive: arrows move you around, space bar is equivalent to clicking.
The DPT supports mirroring or RAID 5; for this configuration I put all four drives into one RAID 5 array. I could have designated one drive as a hot spare, but we needed the drive space, so I used them all. That ends up with about 12 gig of usable space. You begin that process by choosing "Create Array", which lets you choose what type of array, and asks you to choose drives for it. One mistake I made using the tool is that after you say you are done selecting drives (which you signify by clicking "Done"), you have to specifically include them in an array by choosing "Include". If you miss that as I did, you haven't created anything.
Once you either "set" the configuration (a menu choice) or save it and exit, the controller begins building the array. If you simply choose "Set", you can remain in the GUI and watch the progress. It took about 20 minutes to complete on this machine.
After completion, it was time to load SCO. The BTLD called for is "dptr5", and this needs to replace a dptr driver built into OSR5. Unfortunately, the instructions for this could lead someone astray: it tells you to answer the driver conflict by typing "25". This apparently was the address of the dpt driver in some release of SCO, but in the 5.0.5 I loaded it's now at 20. Those instructions need to be made more generic.
The installation was very quick, requiring only twenty minutes of actual time after all questions were answered. It probably would have been even faster if the CDROM were SCSI instead of IDE.
It was the testing after installation that proved the performance of this controller. Before installing other software (RS505a, Visionfs and SCO Proxy Server, Microlite Edge), I fired off 10 foreground tasks (one on each of tty03-tty12) that continuously ran "lr" on the root and redirected the output to a differently named file in /tmp. I then fired off two background jobs doing the same thing on tty01, and two Unix windows on tty02 with the same kind of job. I modified the "sys" crontab to run sar more frequently (every five minutes), and enabled sar. I then proceeded to install the software.
I can honestly say I did not notice the other jobs at all. My installation seemed normal, keyboard response was snappy, I really wouldn't have known anything was going on if I couldn't have heard the disks running, and they were running hard. The run queue was well over 7.8 regularly, and of course was 100% occupied. The "sar -d" showed the drive (actually 4 drives, but it looks like 1 drive to the OS) as 100% busy, transferring over 700 blocks per second, yet avserv remained just over 5 ms throughout, and avwait never exceeded 10.2.
System cpu time ran about 70%, user 26 to 28, but wio never exceeded 2. That's impressive performance for an inexpensive machine.
Of course, such artificial tests really don't prove anything. It
will be a few weeks before this box gets to serve up the real data
it was purchased for, but we'll get the true test of it's strength
then. The current machine handles 25 users in a very disk intensive
program on an IDE drive. It's a good IDE drive, but it is often
brought to it's knees by the load. This box should provide a
© March 1999 Anthony Lawrence. All rights reserved.
Got something to add? Send me email.
(OLDER) <- More Stuff -> (NEWER) (NEWEST)
Printer Friendly Version
Increase ad revenue 50-250% with Ezoic