Slashdot Mirror
Single IDE vs Dual IDE?
jrsimmons asks: "I'm running performance tests on IDE interface configurations
for my company. I've discovered that disk to disk I/O is significantly
faster (in the realm of 30%-40%) when only a single IDE interface
is active versus when two IDE interfaces are active. This is
significant as our servers are used to provide Point-of-Sale
availability for registers in the retail environment, which is heavily
dependent on disk i/o performance for efficiency. I have run the tests
under both Windows and our retail OS (sorry, no Linux) with similar
results. What are some possible explanations for the detrimental
effect the second active ide controller has on disk I/O speed?"
Has anyone measured this deficiency on Linux and other Unices?
I use software RAID under Linux (striping only).
I get almost 100% increase in speed if I have the disks configured as master on two separate controllers instead of master+slave on one.
My other account has a 3-digit UID.
Not to me. I've seen the same 30-40% increase copying data between two disks on the same IDE chain as opposed to the exact same two disks on different IDE chains ever since UDMA support came out.
I believe windows only turns DMA on for the first IDE channel by default. If you are transfering from one channel to another, you might be using PIO mode on one channel and that will definitely slow you down. Go to the properties for your IDE hardware and verify that both channels are using DMA if available.
One IDE drive vs one SCSI drive, you're right; IDE is the way to go. But multiple drives, SCSI spanks all. I often find that the people who swear, up and down, otherwise, are the people who can't afford SCSI. :-)
Vintage computer games and RPG books available. Email me if you're interested.
the two devices on the primary controller could not both be transferring data at the same time, so performance would be hit severely if you were reading or writing to both simultaneously regardless of whether or not the disks were transferring data between each other or some other device on the secondary controller.
when data is transferred between a device on the primary and a device on teh secondary controller there is no performance hit that is caused by the lack of ability to read or write simultaneously; i.e., you can read or write at the same time if each device is on a different controller, but not on the same controller.
now in your case what i think you are saying is that you notice poor performance even in this scenario; i.e., transferring data across two controllers. the reason for this is that IDE is severely CPU dependent. What kind of CPU are you running on these machines? IDE's CPU dependence is what makes it STILL a poor substitute for i/o heavy use when compared with SCSI. SCSI devices are not CPU dependent. as well, you can simultaneously read and write to all devices on the chain. also, transfer speeds are faster and the RPM of SCSI drives tend to be faster as well.
so i would surmise that the reason you are seeing your performance hit is that the CPU is just working twice as hard to transfer data from one controller to the other. if you actually are trying to transfer data across the same controller; i.e, from master to slave or vice versa, you should stop doing that. that's really slow and quite silly. get SCSI. it's worth it.
I believe this is to do with UDMA spec's as to cable length an connectors etc. etc. I reciently had a lot of trouble with a UDMA100 Maxtor drive. They got back to me and informed me that UDMA wouldn't be gaurenteed to even run at UDMA100 (mode 5??) and even if the drive did detect at UDMA100 the performance would be much worse..
Having finally got my drive detecting as UDMA100 I can totally agree with the performance issues under Windows 2000 at any rate. My slave drive gets on average 30Mb/sec when runnning a transfer rate test on top of NTFS. My master drive gets on average 60Mb/sec on the same test.
If you read the installation instructions for all UDMA100 drivers (well all the ones I've seen ;) ) they say to make sure the drive is attached to the black connector on the cable for best performance. I looks like UDMA100 just isn't designed to run both drives on the controller at high speed.
If you ever drop your keys into a river of molten lava, let'em go, because, man, they're gone.
IDE hard drives are very dumb. They are given commands and execute them in the order they are received and require the guidance of a parental figure in order to work properly. They also can't bear to be alone while they do work of any kind. Any time an IDE drive processes a command it takes full control of the IDE bus and cannot release it until all commands issued are complete. If you occupy two channels on an IDE bus one of the drives is going to be losing out hardcore to the other drive when it comes to throughput. If you really want a reliable storage system under either Windows or Linux go with SCSI drives rather than IDE. SCSI drives are smart and don't need their hand held while doing work. SCSI drives will reorder read/write requests so the order they're executed is the most efficient order not just the order received. They also get a command and relinquish control over the bus when they are given commands and can hold commands in a queue until they can get some bandwidth on the bus again. Adding a second drive to a SCSI bus doesn't ruin the performance like with IDE drives. Drives can also talk to one another independent of the host system which means transfering data from a hard drive to CD-R doesn't require the total control of the host CPU like it would with IDE. Meanwhile you can still read and write data to another drive that isn't being used to burn a CD without making anything crap out on you. SCSI costs more but you get better performance out of it. You can pretty readily find 9GB SCSI drives for under 100$ and a couple of them on a RAID controller ought to provide you with plenty of throughput for a long time.
I'm a loner Dottie, a Rebel.