From owner-freebsd-hardware Tue Mar 27 12:50:58 2001 Delivered-To: freebsd-hardware@freebsd.org Received: from edwin.mounet.com (edwin.mounet.com [216.145.76.8]) by hub.freebsd.org (Postfix) with SMTP id 64D1137B718 for ; Tue, 27 Mar 2001 12:50:53 -0800 (PST) (envelope-from hornback@wireco.net) Received: (qmail 17677 invoked by uid 0); 27 Mar 2001 20:34:35 -0000 Received: from unknown (HELO tomcat) (216.145.67.151) by mounet.com with SMTP; 27 Mar 2001 20:34:35 -0000 From: "Andrew C. Hornback" To: "Michael VanLoon" Cc: "FreeBSD Hardware" Subject: SCSI vs. IDE (not a flame war. Was: RE: Server MB suggestions?) Date: Tue, 27 Mar 2001 15:51:46 -0500 Message-ID: <00bc01c0b6ff$bc9263c0$0e00000a@tomcat> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: Importance: Normal Sender: owner-freebsd-hardware@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > -----Original Message----- > From: owner-freebsd-hardware@FreeBSD.ORG > [mailto:owner-freebsd-hardware@FreeBSD.ORG]On Behalf Of Michael VanLoon > Sent: Tuesday, March 27, 2001 3:06 PM > To: 'Andrew C. Hornback'; Joseph Gleason > Cc: FreeBSD Hardware; 'Ed Henderson'; 'Mike Smith' > Subject: RE: Server MB suggestions? > > > > 3) Keep it at one drive per chain. I am no hardware > > expert, but it is my > > > understanding that there are major performance hits if you > > have two drives > > > on a single chain. > > > > That last assertion depends on the controller, the > > drives and the RAID > > schema that you are using (i.e. SCSI). > > > > Hang 4 Ultra160 drives off of a UW controller, and > > you're going to see > > performance dips. Hang 4 UW drives off of an Ultra160 > > controller, and you > > should (if configured properly) see a performance increase. > > Not sure what you were trying to say here... :-) Basically, the limiting factor in disk subsystem performance is the controller. Once you run the controller out of bandwidth, you have basically exhausted the controller to it's performance threshold. Example: 4 drives that can burst at 160 MB/s on a controller that can handle a sustained 40 MB/s transfer is going to limit the drives, no matter how fast they are, to a maximum of 40 MB/s. However; 4 drives that can burst at 40 MB/s on a controller that can handle a sustained 160 MB/s transfer will show no direct performance threshold, given that not all of your drives are going to be bursting at the same time (unless they're made by Quantum, which is a whole different e-mail thread) > > You have to remember that for RAID 1 (or other > > mirroring setups) for every > > read request, you're hardware is actually doing two (or > > more). But, you can > > regain some of that performance by going to a striping schema > > which allows > > the hardware to read across more than one physical drive, > > utilizing higher > > output. > > I think you have that backwards. Reading mirrors, with a good controller, > increases performance, not decreases. A good hardware RAID > controller will > interleave read requests from mirrored drives so you can approach > double the > read throughput of a single drive. Going by the manual for my AMI controller, and from personal experience of having implemented such systems, that's not true. Running a mirrored pair, depending on the way that the controller is configured to read, can give performance at the level of a single drive or below, not above. > And writes should be the same speed (roughly) writing to two > drives as one, > since they're simultaneous. Of course in reality, bus bandwidth > comes into > play, and is one of the reasons lots of installations install each pair of > mirrored drives on separate SCSI busses. The one drive per bus for a mirror is for a couple of reasons. Most controllers have a specific chipset dedicated to each channel. The idea of placing one drive on each bus/channel is so that if you have a hardware failure on the controller, and one of the chips dies, you still have a running machine. Additionally, it's how the drives are matched to the controller. Back to my previous example, if you stick a pair of 80 MB/s drives on an 80 MB/s controller on the same bus, you're not going to be running it at full-bore performance. Additionally, the whole basis behind RAID is to be redundant, in case of hardware failure, so, it would make sense in that application to put one drive on each bus. However, I have always considered RAID 5 to be a more viable alternative, as it utilizes the hardware better. [Much welcomed lauding of SCSI over IDE snipped for brevity] > On the other hand, yes modern IDE drives are fairly well built, > pretty fast, > and cheap cheap cheap. Balance as your needs, comfort level and > budget can > accommodate. Modern IDE drives are fairly well built, but SCSI is still light years ahead, as far as I'm concerned. SCSI has blazed the trail that IDE now follows with higher spindle speeds, higher levels of onboard cache, increased reliability, higher throughput speeds, etc. This could be likened to the Chrysler being followed by Lexus (since they're always in pursuit of perfection), or the whole MS/Linux/FreeBSD thing : "Where would you like to go today? / Where would you like to go tomorrow? / Took ya long enough to get here!" *grins* --- Andy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message