From owner-freebsd-stable Tue Mar 13 10:53:14 2001 Delivered-To: freebsd-stable@freebsd.org Received: from ns1.venon.com (ns1.venon.com [64.7.7.83]) by hub.freebsd.org (Postfix) with ESMTP id C679E37B71A; Tue, 13 Mar 2001 10:53:05 -0800 (PST) (envelope-from all@biosys.net) Received: from megalomaniac.biosys.net (megalomaniac.venon.com [64.7.7.82]) by ns1.venon.com (Postfix) with ESMTP id C85F4D1613; Tue, 13 Mar 2001 13:51:21 -0500 (EST) Message-Id: <4.3.2.7.2.20010313133746.00c718b0@64.7.7.83> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Mar 2001 13:53:05 -0500 To: "Jeffrey J. Mountin" , Jean-Marc Zucconi From: Allen Landsidel Subject: Re: UDMA 33/UDMA 100 perfs Cc: stable@FreeBSD.ORG In-Reply-To: <4.3.2.20010313012614.01fe6b00@207.227.119.2> References: <4.3.2.7.2.20010313013018.00c49fd0@64.7.7.83> <4.3.2.20010313002151.02d94c70@207.227.119.2> <200103130329.f2D3TXN73556@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 01:36 3/13/2001 -0600, Jeffrey J. Mountin wrote: >At 01:39 AM 3/13/01 -0500, Allen Landsidel wrote: > >>The point of a higher bus speed is not to get higher transfer rates from >>a single drive, but to avoid saturating the bus when you have multiple >>drives on a single channel of a controller. This is true of both IDE and SCSI. > >Here we go again. > >Check the archives and consider a retraction of this. I haven't begun digging through yet to find out what was said, but I realize I did say is ambiguous. To make it more clear using SCSI as an example, SCSI standards are designed and standardized with the idea that the current standard will be at least twice as fast as the fastest drive currently available, in sustained transfers. With SCSI-3 (Ultra160, et al) a single channel is almost guaranteed to be three to four times faster than the fastest drive you could attach to it. With ATA-100 this falls to about two and a half times. If you doubt this reasoning behind bus speed increases, ask yourself what the point of RAID levels 0 or 5 would be. >Which is exactly why I said what I said and why I grew sick of >manufactures hyping new transfer standards when no drives could hardly >saturate the previous standard and end lusers think there was something to >gain with their old drives on new controllers. Thats kind of goofy.. I don't know of any mfg that is hyping so much that they claim a controller upgrade only is somehow going to magically give you better performance. They're trying to sell drives. >You forgot or don't know about: > >3) Consider using only one drive per controller for maximum performance. I didn't mention that for two reasons. First, he already said he had only that single drive on that channel. Second.. I assume you meant channel and not controller.. using only one drive per controller would not only be expensive as hell for any amount of capacity (before you ran out of pci slots for controllers) but would also be pointless. As for one drive per channel, I don't even see the point in that unless your only concern is the burst transfer rate, which can only sustain for as large as the drives onboard read cache.. a couple megabytes at most. I'd advise a simple and easy rule. Check the average sustained to media transfer rates of the drives you intend to buy, and at most don't put more drives on a single channel than the bus will be able to make use of. You'll run into the standard consumer flavor of PCIs bottleneck before long anyway @ 132MB/s (4 * 33). -------signature file------- PGP Key Fingerprint: 446B 7718 B219 9F1E 43DD 8E4A 6BE9 D739 CCC5 7FD7 "I don't think [Linux] will be very successful in the long run." "My experience and some of my friends' experience is that Linux is quite unreliable. Microsoft is really unreliable but Linux is worse." -Ken Thompson, Interview May 1999. http://www.freebsd.org FreeBSD - The Power to Serve http://www.rfnj.org Radio Free New Jersey - 375 streams - 96kbps @ 44.1khz http://namespace.org -- http://name.space Resist the ICANN! Support name.space! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message