![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
Ok, it's rare that I need to ask for help, but as I'm weak in the SCSI arena, well, here I go. This is a long post with a lot of info, but that's me: overly thorough just because I can be. 
Here's the setup:
Dell Precision Workstation 530MT - shipped in June 2002 (yes, it's old)
dual Xeon (Prestonia) 2 GHz 512KB L2 processors
2GB of RDRAM 800 (yes, it's slow, but it works, and if I could disable the ECC I would)
2 x 73GB Seagate 73LP 10K RPM Cheetahs U160
Adaptec 29160N onboard SCSI controller (supposedly 64 bit connection to the PCI bus)
Dell PERC3/DC aka AMI MegaRAID 1600 Elite caching U160 RAID controller with 64MB of cache RAM onboard (64 bit PCI card)
That's the stuff that really matters and pertains to the question/situation I'm trying to resolve. The rest is a Plextor PX-760A 18x burner, a WD WD800BB 80GB ATA drive (the ATA drive and the Plextor are on the IDE channels, Masters, no other ATA/IDE hardware).
The situation is this:
When the two Cheetahs are hooked up a U160 cable as ID 0 and ID 1, they work exactly as expected. The Adaptec 29160N sees them as U160 devices, 16 bit bus, and they give proper U160 speeds for the age these drives are (manufactured around early 2001 I believe). They show average reads of about 44MB/s (using HDTach) and burst speeds of 115-120MB/s, right about where they should be. I was expecting closer to 160MB/s because of the U160 bus, but 115-120MB/s is just damned fine with me.
That's as single drives, on the same cable, attached to the onboard Adaptec.
Now is when it gets weird.
I install the PERC3/DC card, which has the latest available firmware on it. I remove the cable from the Adaptec onboard controller, attach it to the PERC3/DC on channel 0 (I've tried channel 1 also, same results), turn the computer back on and disable the onboard Adaptec controller.
When the PERC3/DC BIOS kicks in, it sees the two drives at U160 as it should. That was a problem in itself that I tracked down to a defective U160 SCSI cable with one single break in one of the outer conductors. With that cable, the drives were never seen as anything more than going 40 in sync and 8 bit wide bus. So I resolved that issue with a replacement cable and now the drives work as expected.
The PERC3/DC sees the drives as U160 drives, and that's fine. The issue I'm wondering about comes from when I set up a proper RAID 0 array on the PERC3/DC. When I do that, and then I install XP Pro, or 2K3, or any OS actually I get no better than 65MB/s sustained reads - and really, that's FINE with me, really it is. I know about RAID 0 and it's shortcomings; this RAID 0 thing is for testing to learn more about setting up such arrays, etc.
My problem comes from the burst speeds off that PERC3/DC controller because they never go over 65MB/s either. That's the rub, right there. I would think - hell I would expect that 2 U160 drives working in RAID 0 could do that much for burst speeds. I know that the 65MB/s average read speed is wonderful compared to the single drive(s) maxing out at roughly 44MB/s. But come on, 65MB/s burst? That's crazy.
If one drive can do 44MB/s average reads and then burst at nearly 3x that much (close to 120MB/s as mentioned earlier), then surely two such drives working in tandem should be able to provide a burst speed that can match or exceed the burst speed of one lone drive. Shouldn't that be the case? Especially with a caching RAID controller?
I've tried to narrow down the issue, and right now my suspect appears to be the controller itself. I can't test the drives individually on the PERC3/DC because it's a RAID controller - it won't let me set up each drive as a "volume" without it being attached to an array of some kind off the controller, so that's effectively a testing dead end.
And I don't see any specific way to test the burst speeds directly off the caching controller either. My logic works like this: if one drive can burst at 115MB/s, then surely both of them working together can feed enough data to the cache on the controller for it to give the data up at well over 120MB/s - hell it should be able to hit pretty close to the technical and theoretical limit of 160MB/s and saturate the U160 bus totally.
But that's not happening, and I can't figure out why. My knowledge of SCSI hardware is limited, I admit that, hence me asking for some advice. Are there any freely available SCSI testing tools that might be able to clue me on the severe lack of performance?
I've located information from some old AMI documentation and some postings on a variety of forums that say the MegaRAID 1600 Elite works best and is optimized for Write-Through caching with 64KB stripe size on the array, so that's what I use. I wonder if I'd have to go through all the trouble of multiple installs and reconfiguration to actually test that.
But if the drives can pump 65MB/s average reads across the U160 bus, I can't see why they or the controller can't pump the burst through at double that, or even better.
In HDTach, when the drives are in RAID 0, that 65MB/s average read comes from a min/max of 64 and 67, respectively. It's literally a flat line from the start of the array to the end, all 140-ish gigs of it. That I thought was pretty cool to see that flat line go over the entire span of the data on the platters.
Ok, that's enough info. Someone can either help or maybe tell me what I can check or modify to see what gives. It's not my intention to run RAID 0 on a regular basis; I just do this for learning, so now I need to learn how to maximize the performance in light of some issues.
Thanks...
Here's the setup:
Dell Precision Workstation 530MT - shipped in June 2002 (yes, it's old)
dual Xeon (Prestonia) 2 GHz 512KB L2 processors
2GB of RDRAM 800 (yes, it's slow, but it works, and if I could disable the ECC I would)
2 x 73GB Seagate 73LP 10K RPM Cheetahs U160
Adaptec 29160N onboard SCSI controller (supposedly 64 bit connection to the PCI bus)
Dell PERC3/DC aka AMI MegaRAID 1600 Elite caching U160 RAID controller with 64MB of cache RAM onboard (64 bit PCI card)
That's the stuff that really matters and pertains to the question/situation I'm trying to resolve. The rest is a Plextor PX-760A 18x burner, a WD WD800BB 80GB ATA drive (the ATA drive and the Plextor are on the IDE channels, Masters, no other ATA/IDE hardware).
The situation is this:
When the two Cheetahs are hooked up a U160 cable as ID 0 and ID 1, they work exactly as expected. The Adaptec 29160N sees them as U160 devices, 16 bit bus, and they give proper U160 speeds for the age these drives are (manufactured around early 2001 I believe). They show average reads of about 44MB/s (using HDTach) and burst speeds of 115-120MB/s, right about where they should be. I was expecting closer to 160MB/s because of the U160 bus, but 115-120MB/s is just damned fine with me.
That's as single drives, on the same cable, attached to the onboard Adaptec.
Now is when it gets weird.
I install the PERC3/DC card, which has the latest available firmware on it. I remove the cable from the Adaptec onboard controller, attach it to the PERC3/DC on channel 0 (I've tried channel 1 also, same results), turn the computer back on and disable the onboard Adaptec controller.
When the PERC3/DC BIOS kicks in, it sees the two drives at U160 as it should. That was a problem in itself that I tracked down to a defective U160 SCSI cable with one single break in one of the outer conductors. With that cable, the drives were never seen as anything more than going 40 in sync and 8 bit wide bus. So I resolved that issue with a replacement cable and now the drives work as expected.
The PERC3/DC sees the drives as U160 drives, and that's fine. The issue I'm wondering about comes from when I set up a proper RAID 0 array on the PERC3/DC. When I do that, and then I install XP Pro, or 2K3, or any OS actually I get no better than 65MB/s sustained reads - and really, that's FINE with me, really it is. I know about RAID 0 and it's shortcomings; this RAID 0 thing is for testing to learn more about setting up such arrays, etc.
My problem comes from the burst speeds off that PERC3/DC controller because they never go over 65MB/s either. That's the rub, right there. I would think - hell I would expect that 2 U160 drives working in RAID 0 could do that much for burst speeds. I know that the 65MB/s average read speed is wonderful compared to the single drive(s) maxing out at roughly 44MB/s. But come on, 65MB/s burst? That's crazy.
If one drive can do 44MB/s average reads and then burst at nearly 3x that much (close to 120MB/s as mentioned earlier), then surely two such drives working in tandem should be able to provide a burst speed that can match or exceed the burst speed of one lone drive. Shouldn't that be the case? Especially with a caching RAID controller?
I've tried to narrow down the issue, and right now my suspect appears to be the controller itself. I can't test the drives individually on the PERC3/DC because it's a RAID controller - it won't let me set up each drive as a "volume" without it being attached to an array of some kind off the controller, so that's effectively a testing dead end.
And I don't see any specific way to test the burst speeds directly off the caching controller either. My logic works like this: if one drive can burst at 115MB/s, then surely both of them working together can feed enough data to the cache on the controller for it to give the data up at well over 120MB/s - hell it should be able to hit pretty close to the technical and theoretical limit of 160MB/s and saturate the U160 bus totally.
But that's not happening, and I can't figure out why. My knowledge of SCSI hardware is limited, I admit that, hence me asking for some advice. Are there any freely available SCSI testing tools that might be able to clue me on the severe lack of performance?
I've located information from some old AMI documentation and some postings on a variety of forums that say the MegaRAID 1600 Elite works best and is optimized for Write-Through caching with 64KB stripe size on the array, so that's what I use. I wonder if I'd have to go through all the trouble of multiple installs and reconfiguration to actually test that.
But if the drives can pump 65MB/s average reads across the U160 bus, I can't see why they or the controller can't pump the burst through at double that, or even better.
In HDTach, when the drives are in RAID 0, that 65MB/s average read comes from a min/max of 64 and 67, respectively. It's literally a flat line from the start of the array to the end, all 140-ish gigs of it. That I thought was pretty cool to see that flat line go over the entire span of the data on the platters.
Ok, that's enough info. Someone can either help or maybe tell me what I can check or modify to see what gives. It's not my intention to run RAID 0 on a regular basis; I just do this for learning, so now I need to learn how to maximize the performance in light of some issues.
Thanks...