Quoting Andre M. V. ([EMAIL PROTECTED]): > The original question was this: > "anyway for better performance and your money's worth, go with scsi."
I can't help notice that that's not a question. ;-> Nor was it my post. (I'm looking down at your incredibly long post, and sighing, because I'm anticipating that a large amount of my evening is about to be frittered away. Oh well.) > Consider: > > Standard Clock speed Bus Data Rate(command Rate) > =============================================================== > SCSI (SCSI-1) 5MHz 8bits 5 MB/s > Fast SCSI (SCSI-2) 10Mhz 8bits 10 MB/s > Wide SCSI (SCSI-2) 5Mhz 16bits 10 MB/s > > Now compare it with: > > "Huge And Fast: Western Digital WD1200JB With 8 MB Cache" > http://www4.tomshardware.com/storage/02q1/020305/index.html > > Read Data transfer: 24-49 MB/s > Read Burst Data transfer: 24-49 MB/s > Write Data transfer: 14-39 MB/s > > Bottomline: > Theoretical speed of scsi-1 and scsi-2 standard drives > is no match with the actual speed of the new generation > EIDE HDD. Cost effective too. Congratulations, you've just fooled yourself. Three times. One: Looking at my calendar, I see that it's 2002. Where did you find a 10MHz-bus-limit hard drive? Did you raid a museum? Two: _While_ you were in the museum, you seem to have misread the display. The SCSI-2 bus's maximum transfer rate (current circa 1990) was 10 MHz. Thus, those with wide (16-bit) connectors were subject to a bus ceiling speed of 20MB/sec., not 10MB/sec. Which from 1988 to 1994 was quite liveable. Three: Gee, I can probably claim "24-49 MB" even on _old_ drives if I don't both to flush the caches and read from consecutive sectors in a single-user, single-tasking, single-threaded environment. (Life must be simple when you think like a DOS user.) If you want the reasons why _neither_ ATA nor SCSI drives can individually output data much faster than that, and only approach that under very contrived test conditions, please see this list's archive from around mid-May. > 4.2% CPU usage (anandtech.com) is not a big deal. It can certainly run higher than that. > CPU usage for server and desktops are idle most of the time in the > first place. I certainly agree! In fact, I made that exact point on this mailing list a few few hours ago, as reason why software RAID (the kernel md driver) in particular is strongly worth considering. >> and consumption of IRQs. > > Answer to that is IDE raid controllers in JBOD mode. Yes, but then they're essentially doing IRQ-sharing, which historically has been problematic and is generally something to avoid. An ATA RAID controller in JBOD mode is essentially several separate ATA chains (four in the case of the 3Ware card I'm fond of), each served by separate ATA host adapter circuits that are merely aggregated into (typically) a single VLSI chip. So, you have the equivalent of several ATA controllers, each sharing an interrupt. I recommend the 3Ware card despite this, but with reservations, because IRQ-sharing is just generally unwise. >> With SCSI, you get hot-fix mapping out of bad sectors automatically, > > Does the HDD manufacturer already does this for you? The hard drive manufacturer sets up in the factory the initial bad-sector map and the initial hot-fix region. The drive's on-board circuitry dynamically swaps in storage from the hot-fix region as needed, at the hardware level. I think, but am not certain, that re-low-level-formatting the drive rebuilds the hot-fix area. >> scatter-gather at the hardware level, ability to >> do genuine low-level reformatting right in the host adapter BIOS, > > I certainly hope that this helps SCSI-1 and SCSI-2 HDD performance > compared to the new generation EIDE drives! :) With the money gained by selling -=museum pieces=- like that, you might be able to buy _modern_ SCSI drives instead. But you've never heard of modern SCSI drives, have you? >> more-stable standards, and the ability to usefully have more than one >> drive per chain. > > See above. Seen it. Embarrassed on your behalf. So sorry. >> And ATA 100 is a bit of a sham, because it's only barely possible to >> saturate ATA 66 with fast drives under contrived test conditions, >> and only one drive per chain can be active at a time. > > Not really a sham. In a diff. point of view you are right if you > use EIDE drives the usual way.. The ATA100/133 controllers can > theoretically handle 100/133 Mbytes/sec. and the current ATA HDD in > the market cannot achieve those speeds. > > But if you use IDE RAID you can achieve speeds near 100/133 Mbytes/sec. > *sustained*. That would be an aggregate output of the _drive array as a whole_, I assume. But, in that case, you've just fooled yourself, again. That is, what you're doing there is adding the cumulative output of something like four ATA drives, each on an ATA channel where its limits of physical read speeds will rarely allow it to put out even as much as 33 MB/sec. Maybe under extremely contrived conditions of perfectly, conveninently ordered data, each drive might start approaching 66 MB/sec. But you're not going to, in 2002, see any known drive exceed 66 MB/sec output, because of physical access limits. Period. Honestly, I'll never cease to be amazed at the rubbish people will convince themselves, after they've bought into cheap hardware, and feel a need to justify their mistakes. -- Cheers, The difference between common sense and paranoia is that common sense Rick Moen is thinking everyone is out to get you. That's normal; they are. [EMAIL PROTECTED] Paranoia is thinking they're conspiring. -- J. Kegler _ Philippine Linux Users Group. Web site and archives at http://plug.linux.org.ph To leave: send "unsubscribe" in the body to [EMAIL PROTECTED] To subscribe to the Linux Newbies' List: send "subscribe" in the body to [EMAIL PROTECTED]
