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?
Your results sound strange to me.
For two disks, you should get the best results with both disks configured as masters on two different IDE buses.
If you're not seeing that, I'd check that you have the correct drivers/optimizations for your IDE chipset enabled. You also might want to check IRQ allocation to make sure there's no strange conflicts . Check your windows (NT/2000) event log to make sure there's no strange IDE timeouts indicating hardware issues. If you still see the problem you should try your test on a different hardware platform (motherboard/controller combo).
From your description, however, you might want to go with a raid technology such as RAID 1, RAID 5, or raid 1+0. It will offer much better redundancy and possibly improved performance.
What exactly do you mean by active? There are two drives on one IDE interface? Two Drives, one on each interface? One Drive, And both interfaces turned on in the BIOS?
I'll take for granted that you actually have a good way of measuring drive performance, and it's not just a 'feeling'.
What motherboard/Chipset/PC's are you talking about here? Have you replicated the results on dissimilar hardware?
What was significance of the second active ide controller? were you moving data to two drives?
And finally, Why is your system sooooo dependant on disk I/O? If this is the case, mayhap you need to re-engineer the app somewhat to balance out the disk IO aspect. If it's actually CONSTANTLY saturating one or two IDE channels, Quit being a complete twit, and move to SCSI, where this isn't a problem.
If you actually want help on this, you had better provide a heck of alot more information up front.
G
"...In your answer, ignore facts. Just go with what feels true..."
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.
If you are running I/O intensive applications, there is no subsitute for SCSI. IDE is still too braindead to do the job effectivly with decent interactive, multitasking performance. Don't waste your companies time on fiddling with consumer level hardware in a professional environment.
How much is your time worth? How much is this application worth to your company? In a professional server, SCSI is not expensive.
I'd guess one or both of the drives is not in DMA mode. It's probably configured as PIO mode.
This is a pretty common mistake - if the drive is in PIO mode, all i/o goes through the cpu.
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 know some dick will moderate me down because I was rude, and I used the word 'dick' (which turns all the faggot moderators on), but it's true. If you care about speed, IDE is an inappropriate tool. Take it out of your toolbox, and forget about 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.
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.
Whenever I come across a scenario like this, I tell people to take a step back and before making any technical decisions, figure out what it is you are actually trying to accomplish. If you are really after high performance, get SCSI disks. If you're after cheapness, then you will simply have to accept that IDE disks are slower.
This isn't a question for a techie to answer, BTW. One of your business managers will have to think about how many transactions per day are processed, when the cost of the system can be recouped at a given percentage of each transaction, whether or not paying more for SCSI makes financial sense, and whether higher unit cost will mean you sell fewer units. Get one of your tame MBAs to think about this for you.