Debate Concluded

There are other more significant disadvantages to the use of IDE mode, only a few of which are touched on by the Benchmark Reviews piece:

  • Placing an AHCI capable controller into IDE mode disables hot-swap support. This precludes the ease of use of most eSATA ports, as the system would behave improperly or even blue screen if devices were hotplugged. The user would have to shut down the system to add or remove an eSATA device.
  • No port-multiplier support, which requires AHCI to function. Some external multi-bay devices rely on port multipliers and RAID-enabled controllers.
  • For all RAID-able on-board SATA controllers, RAID mode is an extension of AHCI mode. There is no way around this. Want to use IDE-only mode? No RAID for you.
  • There are AHCI-specific advanced power management features. These help reduce power consumption above and beyond what an IDE-only device is capable of.  Without these added reduced power states, users will likely see reduced battery life in most usage scenarios.
  • Loss of write combining support. SSD’s that are able to combine random writes into single blocks of flash will suffer greatly, as they tend to combine writes issued to the drive in a parallel fashion. Since IDE mode does not support the required parallelism, less writes will be combined, resulting in increased wear to the flash memory.
  • HDD’s installed on the same controller will see a significant hit in performance when unable to use NCQ. The drive would not be able to re-sequence IO requests in an optimal way, forcing additional unnecessary wear to the head pack.

If AHCI is so good then why was IDE FASTER?!?!

Aside from inconsistencies in HDTune, when testing only single-threaded performance, IDE may perform marginally better than AHCI.  The physical interface may be identical, but AHCI adds some additional instructions / overhead to the protocol, which slightly detract from the bandwidth available for data transfers.  This slight performance hit is nullified by the performance gains seen when the attached device can utilize parallel IO (through the use of NCQ).

Why didn’t Benchmark Reviews use the correct benchmarks?

Using something easy like ATTO would have been quicker and easier than HDTune, and since ATTO is a multi-threaded benchmark, it would have shown the differences quite easily.  Another alternative is IOMeter.  In the article comments, I found the author’s justification for avoiding IOMeter:

Also, have you used Iometer before for yourself? If so I’m sure you know that there are so many different settings that you can’t just tell someone to ‘use Iometer’ and expect their results to match yours.” 

IOMeter is known for its high degree of customization.  Part of that customization is the ability to issue commands at specific Queue Depths (i.e. simulating multi-threaded / NCQ scenarios).  It’s not terribly difficult to instruct IOMeter to run a test at a specific Queue Depth, either.  As a matter of fact, it’s one of the first settings you are prompted with:

*Updated* Benchmark Performance SSD Testing: AHCI vs IDE (or perhaps not) - Storage 5

But what about TRIM?

The article points out that TRIM works under IDE mode, but that’s only correct if you’re using the Microsoft-provided IDE / AHCI driver under Windows 7. The point is moot, however, as the review failed to conduct any TRIM-specific performance testing. TRIM can not be parallelized when in IDE mode, and therefore an active OS issuing TRIM to an IDE-mode SSD would see an overall drop in performance. This is because other read / write commands would have to wait until the SSD serviced each TRIM command.  This is above and beyond the performance hit caused by limiting the SSD to handling instructions sequentially (IDE mode) in the first place.

“Why doesn’t PC Perspective do an article on this?”

There is simply no need to do so. The article would be boring as our IOMeter test graphs would be all horizontal lines.  Other single-threaded tests would show only slight differences between AHCI and IDE. It would be a very dry article indeed.  Besides, my very first article for PCPer touched on the subject.  It’s amazing how quickly the difference can be shown when using a benchmark (and an SSD) capable of properly demonstrating the difference:

*Updated* Benchmark Performance SSD Testing: AHCI vs IDE (or perhaps not) - Storage 6
X25-M with AHCI disabled (BIOS in ‘IDE’ mode).

*Updated* Benchmark Performance SSD Testing: AHCI vs IDE (or perhaps not) - Storage 7
NCQ in action (BIOS in ‘AHCI’ mode).

The above test was with the original Intel X25-M under an ICH10R controller.  Note that AHCI mode boosts the smaller data transfer performance by as much as 2-3x and gives sequential read performance a 30 MB/sec bump as well.  Write performance was limited to 80 MB/sec by the tested drive regardless of interface mode.


The overclocking crowd goes nuts to squeeze every possible bit of performance out of their hardware. Those reading the Benchmark Reviews article are likely to waste countless hours going for those few percentage points in single-threaded benchmarks, only to find their *real* (multi-threaded) performance has suffered significantly.  I urge those system tweakers out there to do some additional research before dropping your personal systems back down to IDE mode.

** Edit **

Benchmark Reviews has posted up a new article which includes additional multi-threaded benchmarks.

** End Edit **

Further Reading:

As such, I take the article as an insult to other storage reviewers out there who research their SSD testing as completely as possible.  Now we must all run interference, correcting those end users who had mistakenly taken incorrect information as gospel.  Suggesting that everyone voluntarily take a huge step back in storage interface technology just to get a few percentage point gain in single-threaded performance is nothing short of mind boggling.

« PreviousNext »