Similar experiences with HP and their SmartArray 5i controller on Linux. The answer was: "this controller has won awards for performance! It can't be slow!", so we made them test it in their own labs an prove just how awfully slow it was. In the case of the 5i, it became apparent that HP had no internal expertise on Linux and their controllers, the driver was built by a third party that they didn't support and their performance people didn't deal with the 5i at all. In the end, all manner of benchmarks after you've purchased aren't a good substitute for the up front question: do you have documentation of the performance of your RAID controller on [Linux, Solaris, ...]? I would like everyone who purchases IBM, Dell, HP or Sun to demand that documentation - then perhaps we'd see higher quality drivers and hardware result. - Luke On 11/8/06 8:34 AM, "Merlin Moncure" <mmoncure@xxxxxxxxx> wrote: > On 11/8/06, Markus Schaber <schabi@xxxxxxxxxxxx> wrote: >> Hi, Brian, >> >> Brian Hurt wrote: >> >>> So the question is: is there an easy to install and run, read-heavy >>> benchmark out there that I can wave at them to get them to fix the >>> problem? >> >> For sequential read performance, use dd. Most variants of dd I've seen >> output some timing information, and if not, do a "time dd >> if=/your/device of=/dev/null bs=1M" on the partition. > > we had a similar problem with a hitachi san, the ams200. Their > performance group refused to admit the fact that 50mb/sec dd test was > a valid performance benchmark and needed to be addressed. Yes, that > was a HITACHI SAN, the AMS200, which hitachi's performance group > claimed was 'acceptable performance'. This was the advice we got > after swapping out all the hardware and buying an entitlement to > redhat enterprise which we had to do to get them to talk to us. > > oh, the unit also lost a controller after about a week of > operation...the unit being a HITACHI SAN, the AMS200. > > any questions? > > merlin > > p.s. we have had good experiences with the adtx. > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster >
