Обсуждение: H/W RAID 5 on slower disks versus no raid on faster HDDs
Hi folks, I have two options: 3*18 GB 10,000 RPM Ultra160 Dual Channel SCSI controller + H/W Raid 5 and 2*36 GB 15,000 RPM Ultra320 Dual Channel SCSI and no RAID Does anyone opinions *performance wise* the pros and cons of above two options. please take in consideration in latter case its higher RPM and better SCSI interface. Regds Mallah. -- Rajesh Kumar Mallah, Project Manager (Development) Infocom Network Limited, New Delhi phone: +91(11)6152172 (221) (L) ,9811255597 (M) Visit http://www.trade-india.com , India's Leading B2B eMarketplace.
raid 0 (striping) spreads the load over multiple spindels, the same way raid 5 does. but raid 5 always needs to calculate parity and write that to it's parity drive. RPM isn't that critical, a lot depends on the machine, the processor and the memory (and the spped with which the processor can get to the memory). I have recently tested a lot of systems with some database benchmarks we wrote here at work. We're not running Postgres here at work, sorry, these benchmarks are of no use to Postgres ... We we found is that a lot depends on motherboard design, not so much on drive speed. We got to stages where we allocated 1.8 GB of RAM to shared memory for the database server process, resulting in the entire database being sucked into memory. When doing reads, 100% of the data is coming out the that menory, and drive speed becomes irrelevant. From tests I did with Postgres on my boxes at home, I can say: The more shared memory you can throw at the server process, the better. Under MacOS X I wasn't able to allocate more than 3 MB, Under Linux, I can allocate anything I want to, so I usually start up the server with 256 MB. The difference? A process which takes 4 minutes under Linux, takes 6 hours under MacOS - same hardware, same drives, different memory settings. Best regards, Chris On Thursday 21 November 2002 12:02, you wrote: > Thanks Chris, > > does raid0 enhances both read/write both? > > does rpms not matter that much? > > regds > mallah. > > On Thursday 21 November 2002 22:27, you wrote: > > RAID 5 gives you pretty bad performance, a slowdown of about 50%. For > > pure performance, I'd use the 3 18 GB drives with RAID 0. > > > > If you need fault tolerance, you could use RAID 0+1 or 1+0 but you'd need > > an even number of drives for that, of which half would become 'usable > > space'. > > > > Best regards, > > Chris > > > > On Thursday 21 November 2002 11:45, you wrote: > > > Hi folks, > > > > > > I have two options: > > > 3*18 GB 10,000 RPM Ultra160 Dual Channel SCSI controller + H/W Raid 5 > > > and > > > 2*36 GB 15,000 RPM Ultra320 Dual Channel SCSI and no RAID > > > > > > Does anyone opinions *performance wise* the pros and cons of above > > > two options. > > > > > > please take in consideration in latter case its higher RPM and better > > > SCSI interface. > > > > > > > > > > > > Regds > > > Mallah. -- Network Grunt and Bit Pusher extraordinaire
Mallah, I agree with Chris. The fastest is to have an in memory database. Raid 0 (striping) will speed up both reading and writing since you have more available disk I/O bandwidth. SCSI320 in theory is twice as fast as SCSI160. But the bottleneck will be the throughput of the individual disks. 15,000 rpm of course will be faster than 10,000 rpm. More interesting then the rpm numbers itself are seek time and transfer rate. In a production environment I would always favor some kind of error protection. Either RAID 5 or RAID 1 (mirroring). A hardware RAID controller is faster than software RAID. For pure speed raw devices would be faster then file systems. However, PostgeSQL currently does not support them. Given your 2 choices b) should be faster. a) 3*18 GB 10,000 RPM Ultra160 Dual Channel SCSI controller + H/W Raid 5 b) 2*36 GB 15,000 RPM Ultra320 Dual Channel SCSI and no RAID Option b) can be improved by using striping. Save your money on the SCSI Ultra320 since the disk cant transfer enough data anyway and buy more memory instead. And finally good application design has a greater impact on performance than a little faster hardware. Regards, Nikolaus Dilger On Thu, 21 Nov 2002, Chris Ruprecht wrote: > > raid 0 (striping) spreads the load over multiple > spindels, the same way raid 5 > does. but raid 5 always needs to calculate parity and > write that to it's > parity drive. > > RPM isn't that critical, a lot depends on the machine, > the processor and the > memory (and the spped with which the processor can get > to the memory). I have > recently tested a lot of systems with some database > benchmarks we wrote here > at work. We're not running Postgres here at work, > sorry, these benchmarks are > of no use to Postgres ... > We we found is that a lot depends on motherboard > design, not so much on drive > speed. We got to stages where we allocated 1.8 GB of > RAM to shared memory for > the database server process, resulting in the entire > database being sucked > into memory. When doing reads, 100% of the data is > coming out the that > menory, and drive speed becomes irrelevant. > > From tests I did with Postgres on my boxes at home, I > can say: The more shared > memory you can throw at the server process, the better. > Under MacOS X I > wasn't able to allocate more than 3 MB, Under Linux, I > can allocate anything > I want to, so I usually start up the server with 256 > MB. The difference? A > process which takes 4 minutes under Linux, takes 6 > hours under MacOS - same > hardware, same drives, different memory settings. > > Best regards, > Chris > > On Thursday 21 November 2002 12:02, you wrote: > > Thanks Chris, > > > > does raid0 enhances both read/write both? > > > > does rpms not matter that much? > > > > regds > > mallah. > > > > On Thursday 21 November 2002 22:27, you wrote: > > > RAID 5 gives you pretty bad performance, a slowdown > of about 50%. For > > > pure performance, I'd use the 3 18 GB drives with > RAID 0. > > > > > > If you need fault tolerance, you could use RAID 0+1 > or 1+0 but you'd need > > > an even number of drives for that, of which half > would become 'usable > > > space'. > > > > > > Best regards, > > > Chris > > > > > > On Thursday 21 November 2002 11:45, you wrote: > > > > Hi folks, > > > > > > > > I have two options: > > > > 3*18 GB 10,000 RPM Ultra160 Dual Channel SCSI > controller + H/W Raid 5 > > > > and > > > > 2*36 GB 15,000 RPM Ultra320 Dual Channel SCSI and > no RAID > > > > > > > > Does anyone opinions *performance wise* the pros > and cons of above > > > > two options. > > > > > > > > please take in consideration in latter case its > higher RPM and better > > > > SCSI interface. > > > > > > > > > > > > > > > > Regds > > > > Mallah. > > -- > Network Grunt and Bit Pusher extraordinaire > > > ---------------------------(end of > broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > <a href="http://mail.dilger.cc/jump/http://www.postgresql.org/users-lounge/docs/faq.html">http://www.postgresql.org/users-lounge/docs/faq.html</a>
>>>>> "Nikolaus" == Nikolaus Dilger <nikolaus@dilger.cc> writes: Nikolaus> SCSI320 in theory is twice as fast as SCSI160. But the Nikolaus> bottleneck will be the throughput of the individual disks. Nikolaus> 15,000 rpm of course will be faster than 10,000 rpm. More Nikolaus> interesting then the rpm numbers itself are seek time and Nikolaus> transfer rate. More to the point, with current disks, SCSI160 needs 3 to 4 disks to be saturated. Don't buy 320 unless you have more than 4 disks. Nikolaus> In a production environment I would always favor some kind Nikolaus> of error protection. Either RAID 5 or RAID 1 (mirroring). A Nikolaus> hardware RAID controller is faster than software RAID. I'm on a bit of a mission to stamp out this misconception. In my testing, all but the most expensive hardware raid controllers are actually slower than FreeBSD's software RAID. I've done my tests with a variety of controllers with the same data load and the same disks. As with any test, I have a theory: that the 2Ghz+ main processors of modern machines so outstrip most raid controllers that it is faster to perform the RAID on the main processor. It is also lower latency ... and latency is what matters for advanced filesystems. Nikolaus> For pure speed raw devices would be faster then file Nikolaus> systems. However, PostgeSQL currently does not support Nikolaus> them. This used to be true on machines with less processor power than disk bandwidth. It is likely no longer true. To be more exact: yes, filesystems have overhead, but the overhead is processor overhead ... of which (compared to disk bandwidth) you have lots. OSs have also become more efficient. Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================
On Mon, 2002-11-25 at 23:03, David Gilbert wrote: > > I'm on a bit of a mission to stamp out this misconception. In my > testing, all but the most expensive hardware raid controllers are > actually slower than FreeBSD's software RAID. I've done my tests with > a variety of controllers with the same data load and the same disks. > Hi there, Interesting observation. But I am just curious; is this still valid when you have a DB server with, say, 95+% CPU utilisation??!! (I guess we all know that if one don't get high CPU utilisation on a DB server, either the owner has had too much money, or the DBA has some fine tuning to do). Hossein
David, The answer is always: It depends. Of course can software RAID be faster than hardware RAID. But then you are not comparing the best offerings of each category. Software RAID is usually cheaper than hardware. But again you may be able to construct a product pairing where it is reverse. However, my main point was to use RAID in a production environment to protect against hardware failures. raw versus file system is an old battle. raw is faster because it does not have the filesystem overhead. However, raw is a little harder to administer. Question is how much faster raw is and if it is worth the trouble. Numbers usually quoted are 10-20%. And here things may be changing as operating systems and chaching algorithems get better to mask the file system overhead. As I mentioned the question is mute for PostgeSQL because raw is currently not supported. Regards, Nikolaus Dilger From http://linas.org/linux/raid.html If the RAID disk controller has a modern, high-speed DSP/controller on board, and a sufficient amount of cache memory, it can outperform software RAID, especially on a heavily loaded system. However, using and old controller on a modern, fast 2-way or 4-way SMP machine may easily prove to be a performance bottle-neck as compared to a pure software-RAID solution. Some of the performance figures below provide additional insight into this claim. From http://www.uni-mainz.de/~neuffer/scsi/what_is_raid.html Hardware vs. Software RAID Just like any other application, software-based arrays occupy host system memory, consume CPU cycles and are operating system dependent. By contending with other applications that are running concurrently for host CPU cycles and memory, software-based arrays degrade overall server performance. Also, unlike hardware-based arrays, the performance of a software-based array is directly dependent on server CPU performance and load. On Sun, 24 Nov 2002, David Gilbert wrote: > > >>>>> "Nikolaus" == Nikolaus Dilger > <nikolaus@dilger.cc> writes: > > Nikolaus> SCSI320 in theory is twice as fast as > SCSI160. But the > Nikolaus> bottleneck will be the throughput of the > individual disks. > Nikolaus> 15,000 rpm of course will be faster than > 10,000 rpm. More > Nikolaus> interesting then the rpm numbers itself are > seek time and > Nikolaus> transfer rate. > > More to the point, with current disks, SCSI160 needs 3 > to 4 disks to > be saturated. Don't buy 320 unless you have more than > 4 disks. > > Nikolaus> In a production environment I would always > favor some kind > Nikolaus> of error protection. Either RAID 5 or RAID 1 > (mirroring). A > Nikolaus> hardware RAID controller is faster than > software RAID. > > I'm on a bit of a mission to stamp out this > misconception. In my > testing, all but the most expensive hardware raid > controllers are > actually slower than FreeBSD's software RAID. I've > done my tests with > a variety of controllers with the same data load and > the same disks. > > As with any test, I have a theory: that the 2Ghz+ main > processors of > modern machines so outstrip most raid controllers that > it is faster to > perform the RAID on the main processor. It is also > lower latency > ... and latency is what matters for advanced > filesystems. > > Nikolaus> For pure speed raw devices would be faster > then file > Nikolaus> systems. However, PostgeSQL currently does > not support > Nikolaus> them. > > This used to be true on machines with less processor > power than disk > bandwidth. It is likely no longer true. To be more > exact: yes, > filesystems have overhead, but the overhead is > processor overhead > ... of which (compared to disk bandwidth) you have > lots. OSs have > also become more efficient. > > Dave. > > -- > ============================================================================ > |David Gilbert, Velocet Communications. | Two > things can only be | > |Mail: dgilbert@velocet.net | equal > if and only if they | > |<a href="http://mail.dilger.cc/jump/http://daveg.ca">http://daveg.ca</a> | are > precisely opposite. | > =========================================================GLO================
>>>>> "nikolaus" == nikolaus <nikolaus@dilger.cc> writes: nikolaus> Of course can software RAID be faster than hardware RAID. nikolaus> But then you are not comparing the best offerings of each nikolaus> category. Software RAID is usually cheaper than hardware. nikolaus> But again you may be able to construct a product pairing nikolaus> where it is reverse. No... I admit... if you're willing to spend huge $$'s, there exist hardware solutions that outpace software. It usually means that you have hardware that is more powerful than your main system, though. Often more costly, too. nikolaus> raw versus file system is an old battle. raw is faster nikolaus> because it does not have the filesystem overhead. However, nikolaus> raw is a little harder to administer. Question is how much nikolaus> faster raw is and if it is worth the trouble. Numbers nikolaus> usually quoted are 10-20%. And here things may be changing nikolaus> as operating systems and chaching algorithems get better to nikolaus> mask the file system overhead. As I mentioned the question nikolaus> is mute for PostgeSQL because raw is currently not nikolaus> supported. Well... I don't think your raw write performance (in, say, FreeBSD) would be any more than 5% better than filesystem writing. Old filesystem overhead consisted of the in-order writes that were required to update filesystem metadata... which (consequently) was about 20% in-order (vs. un-ordered) writes. Softupdates (FreeBSD) only requires 1%-ish (or less) in-order writes (or to put it another way: 1% of writes chosen before they would otherwise happen). DAve. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================
>>>>> "Hossein" == Hossein S Zadeh <hossein@bf.rmit.edu.au> writes: Hossein> On Mon, 2002-11-25 at 23:03, David Gilbert wrote: >> I'm on a bit of a mission to stamp out this misconception. In my >> testing, all but the most expensive hardware raid controllers are >> actually slower than FreeBSD's software RAID. I've done my tests >> with a variety of controllers with the same data load and the same >> disks. Hossein> Hi there, Interesting observation. But I am just curious; is Hossein> this still valid when you have a DB server with, say, 95+% Hossein> CPU utilisation??!! (I guess we all know that if one don't Hossein> get high CPU utilisation on a DB server, either the owner has Hossein> had too much money, or the DBA has some fine tuning to do). Typically, the limit on the speed of disk transactions in a modern system is latency. The amount of CPU required to perform a RAID 5 calculation is trivial and RAID 1 scheduling (done efficinetly) is even less demanding on a CPU. ... the latency is the time between when we decide to do the action and when it is able to be done (in this case). In the software RAID-5 case, we need to schedule two reads, perform a caluclation when they return and then schedule two writes. This all happens within the OS's decision to write a block and the block actually being written (and it's why RAID 5 is very slow at writing). RAID-1 writing is simpler ... the Os needs to schedule two writes instead of one. In the hardware case, the OS schedules a write, then it's transferred to the RAID card ... where the RAID card must then schedule the reads and writes. ... which is fine if the RAID card has sufficient buffer... but when things approach saturation of the disk you start to get a number of effects. - if a read doesn't occur before the write must be flushed to disk, nothing is saved by not committing it immediately. - The OS has a good handle on what the data represents and is likely flushing it fairly optimally. Think: your primary CPU is 2Ghz (or more) and your main memory is 1G (or more). Your moderately expensive RAID card is a 100Mhz RISC chip with 64M of memory. How much is this helping? Not much. Remember: hardware RAID is simply RAID software running on another processor. Dave. -- ============================================================================ |David Gilbert, Velocet Communications. | Two things can only be | |Mail: dgilbert@velocet.net | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================
Hi, > In a production environment I would always favor some > kind of error protection. Either RAID 5 or RAID 1 > (mirroring). A hardware RAID controller is faster than > software RAID. Considering the speed of CPU's and busses these days, software RAID can be a lot faster than hardware RAID in many cases. I prefer hardware RAID myself because of the simplicity (the OS doesn't need to know about the RAID configuration), but I hear good results from people running on software RAID. Hope this helps you. Sander.
operationally, disk subsystems trump software raid for primary dataset storage: battery backed cache - safety first. portability - plug it into any other host, or more than one host on the scsi bus (fc-al loop). raid on a pci card or raid on the motherboard need not apply less they sport battery and most don't. worst of both worlds imho, no protection of software and the higher cost of hardware. often software raid is used to mirror the boot disks for transparent boot disk failover, while the primary dataset is on a hardware raid on a scsi bus with two hosts for transparent host failover. but the question, if i can restate it, was ``which is faster?'' -high algorithm overhead and slower devices -low algorithm overhead and faster devices did i miss some nuance of the original question? it seems obvious that lower overhead and faster devices will be faster. but it doesn't matter which one is faster. operationally, as long as the performance is adequate, real disk subsystems are always preferred for primary dataset storage. ----- Original Message ----- From: "Sander Steffann" <sander@steffann.nl> To: <chris@ruprecht.org>; "Nikolaus Dilger" <nikolaus@dilger.cc> Cc: <mallah@trade-india.com>; <pgsql-admin@postgresql.org> Sent: Monday, November 25, 2002 2:43 AM Subject: Re: [ADMIN] H/W RAID 5 on slower disks versus no raid on faster HDDs : Hi, : : > In a production environment I would always favor some : > kind of error protection. Either RAID 5 or RAID 1 : > (mirroring). A hardware RAID controller is faster than : > software RAID. : : Considering the speed of CPU's and busses these days, software RAID can be a : lot faster than hardware RAID in many cases. I prefer hardware RAID myself : because of the simplicity (the OS doesn't need to know about the RAID : configuration), but I hear good results from people running on software : RAID. : : Hope this helps you. : Sander. : : : ---------------------------(end of broadcast)--------------------------- : TIP 6: Have you searched our list archives? : : http://archives.postgresql.org :
On Mon, Nov 25, 2002 at 11:43:56AM +0100, Sander Steffann wrote: > > (mirroring). A hardware RAID controller is faster than > > software RAID. > lot faster than hardware RAID in many cases. I prefer hardware RAID myself > because of the simplicity (the OS doesn't need to know about the RAID > configuration), but I hear good results from people running on software > RAID. yes, hw raid is simply, but it's slow. i've tested it many brand machine. ibm serveraid card w/ raid5 is about HALF speed than sw raid. according to bonnie++, debian, 2.4.19+grsec kernel. the machine ibm xseries 255, 2 xeon mp cpus, 4x18G 10k rpm disk. the bonnie tested with 6G files, 1.5G physical ram and 1G swap. if somebody needs those results, i can send it. -- CZW
Hi all, On Monday 25 November 2002 05:43, Sander Steffann wrote: > Hi, > > > In a production environment I would always favor some > > kind of error protection. Either RAID 5 or RAID 1 > > (mirroring). A hardware RAID controller is faster than > > software RAID. > > Considering the speed of CPU's and busses these days, software RAID can be > a lot faster than hardware RAID in many cases. I prefer hardware RAID > myself because of the simplicity (the OS doesn't need to know about the > RAID configuration), but I hear good results from people running on > software RAID. Stability is an issue here. While the OS might get a code corruption in the kernel by who-knows-what, this is less likely to happen in the on-board memory (RAM/ROM) of the RAID controller. If the system crashes for whatever reason, who knows what gets written back to the disks. Most likely nothing, since the OS already died. Your RAID controller will most likely still flush it's buffers back to disk and leave everything as good as it gets. just my 2c. Best regards, Chris -- Network Grunt and Bit Pusher extraordinaire
On Mon, 2002-11-25 at 23:03, David Gilbert wrote: > > I'm on a bit of a mission to stamp out this misconception. In my > testing, all but the most expensive hardware raid controllers are > actually slower than FreeBSD's software RAID. I've done my tests with > a variety of controllers with the same data load and the same disks. > I agree 100%: hardware raid sucks. We had a raid 5 Postgres server on midgrade hardware with 5 60gig 7200rpm IDE disks (240 gig total) and the thouroughput was just as high (maybe 10% less) than a single disk. Same for the seek times. CPU around 1Ghz never hit more than 10% for the raid service. Since very few databases are CPU limited, this is a small price to pay. We confirmed the performance results with heavy testing. There is virtually no disadvatage to software raid, just spend 10$ and get a 10% faster cpu. The linux software raid drivers (and others I assume) are very optimized. Not to sure about m$ but win2k comes with raid services, its pretty reasonalbe to believe they work ok. You can double the performance of a raid system by going 0+x or x+0 (eg 05 or 50). just by adding drives. This really doubles it, and an optmized software driver improves the seek times too by placing the idle heads it different places on the disks. p.s. scsi is a huge waste of money and is no faster than IDE. IMHO, scsi's only advantage is longer cables. Both interfaces will soon be obsolete with the coming serial ATA. High rpm disks are very expensive and add latent heat to your system. Western digitial's IDE disks outperform even top end scsi disks at a fraction of a cost. You can install a 4 drive 10 raid setup for the cost of a single 15k rpm scsi disk that will absolutely blow it away in terms of performance (reliability too). Just remember, don't add more than one IDE disk on a raid system to a single IDE channel! Also, do not attempt to buy IDE cables longer than 18"..they will not be reliable. Merlin
On Wed, Nov 27, 2002 at 01:16:35PM -0500, Merlin Moncure wrote: > I agree 100%: hardware raid sucks. I've been mostly ignoring this thread, but I'm going to jump in at this point. > We confirmed the performance results with heavy testing. There is virtually > no disadvatage to software raid, just spend 10$ and get a 10% faster cpu. Define heavy testing. I can do sequential selects on a low end PC with one client and have it perform as well as an E10K. I could also fire up 600 clients doing seemingly random queries and updates and reduce the same low end PC to a smoldering pile of rubble. It'd be easy to fudge the results of the "heavy testing" to match what I wanted to believe. > The linux software raid drivers (and others I assume) are very optimized. As are the Solaris drivers, and many others. But there is more to a RAID array than drivers. There's the stability of the controller chipsets and the latency involved in getting data to and from the devices. Would you feel comfortable if you knew the state data for the aircraft you're travelling on was stored on IDE software RAID? Part of the point of hardware raid is that it does do a small set of operations, and therefore far easier to specify and validate the correct operation of the software and hardware. > p.s. scsi is a huge waste of money and is no faster than IDE. IMHO, scsi's > only advantage is longer cables. Both interfaces will soon be obsolete with > the coming serial ATA. Don't get me wrong, I'm a huge fan of IDE RAID in the right locations, but comments like this reflect a total lack of understanding what makes SCSI a better protocol over IDE. Disconnected operation is one _HUGE_ benefit of SCSI, simply being the ability for the CPU and controller to send a command, and then both head off to do another task while waiting for data to be returned from the device. Most (that is most, not all) IDE controllers are incapable of this. Another is command reordering (which I believe SATA does have), being the reordering of requests to better utilise each head sweep. This feature comes into play far more obviously when you have many clients performing operations across a large dataset where the elements have no immediate relationship to each other. It is amplified when your database of such a size, and used in a way that you have multiple controllers with multiple spools. SCSI is not about speed to and from the device, although this does end up being a side effect of the design. It's about latency, and removal of contention from the shared bus. Ultra/320 devices in reality are no faster than Ultra/160 devices. What is faster, is that you can now have 4 devices instead of 2 on the same bus, with lower request latency and no reduction in throughput performance. SCSI also allows some more advanced features too. Remote storage over fibre, iSCSI, shared spools just to name a few. > High rpm disks are very expensive and add latent heat to your system. If you have a real justification for SCSI in your database server, you probably do have both the cooling and the budget to accomodate it. > Western digitial's IDE disks outperform even top end scsi disks at a > fraction of a cost. Complete and utter rubbish. That's like saying your 1.1 litre small city commuter hatch can outperform a 600hp Mack truck. Yes, in the general case it's quite probable. Once you start shuffling real loads IDE will grind the machine to a halt. Real database iron does not use normal IDE. > You can install a 4 drive 10 raid setup for the cost of a single 15k > rpm scsi disk that will absolutely blow it away in terms of performance See above. Raw disk speed does not equal performance. Database spool performance is a combination of a large number of factors, one being seek time, and another being bus contention. > (reliability too). Now you're smoking crack. Having run some rather large server farms for some very large companies, I can tell you with both anecdotal, and recorded historical evidence that the failure rate for IDE was at least double, if not four times that of the SCSI hardware. And the IDE hardware was under much lower loads than the SCSI hardware. > Just remember, don't add more than one IDE disk on a raid system to a single > IDE channel! Also, do not attempt to buy IDE cables longer than 18"..they > will not be reliable. So now you're pointing out that you share PCI bus interrupts over a large number of devices, introducing another layer of contention and that you'll have to cable your 20 spool machine with 20 cables each no longer than 45cm. Throw in some very high transaction rates, and a large data set that won't fit in your many GB of ram. I believe the game show sound effect would be similar to "Bzzzt". IDE for the general case is acceptable. SCSI is for everything else. -- David Jericho Senior Systems Administrator, Bytecomm Pty Ltd -- Scanned and found clear of viruses by ENTIREScan. http://www.entirescan.com/