AHCI slower than IDE :-P

[Corazon]

Not a request for help, just something I wanted to share. I'm sure there's one or two opinions waiting to be heard.

So, I switched my SATA controller over to AHCI from IDE, since I have a new OCZ Vertex Plus 60GB SSD...enabled the registry setting for the MSAHCI driver before rebooting and everything is beautiful. Just as before.

Just as before? Not quite. LOL. See for yourself...


ATTO benchmark results - IDE mode

ATTO benchmark results - AHCI mode

In AHCI, performance actually drops across the board, just slightly - except that reading large blocks gets a few MB/sec faster starting with 128KB blocks.

Hmm. I was expecting a tiny bit more. But now that I'm on AHCI I'll leave it, even if there's no actual advantage it's nice to know NCQ is enabled.

 

[logicearth]

Umm...Those test do not have any dependency on whether you are using IDE or AHCI the result will be the same. Also you cannot take performance results at face value when comparing. You need a threshold. You can test the same drive over and over again without changing anything and the numbers will change, fluctuate up and down every time. You need to take that into consideration when comparing results.

 

[Corazon]

No dependency? I understand that ATTO is one of the best disk benchmarks for SSDs because it can queue I/O requests and put NCQ to work that way. I do realize, though, that NCQ would have more of an effect with harddisks and their comparatively huge access times.

What you're saying suggests there would be no difference between IDE and AHCI, period. I'm sure some people would beg to differ...

And I'm well aware of fluctuations from test to test, but the conclusion remains that in my particular case, AHCI brought very little advantage.

Do you think something was wrong with my testing methodology? Or have suggestions for other benchmark apps?

 

[logicearth]

There is no performance difference to IDE or AHCI because they are only communication protocols. The actual physical SATA connection is what determines the speed. Not whether you are using IDE or AHCI. IDE and AHCI will preform the same because the SATA connection is the same speed regardless.

 

[bej]

FWIW
I had called Gigabyte several months ago about changing from IDE to AHCI. The tech told me they (Gigabyte) had found little speed difference between the two.

 

[Phone Man]

My understanding is that the Trim command will not work in IDE mode so AHCI mode is best for SSD drives.

Jim

 

[Corazon]

There is no performance difference to IDE or AHCI because they are only communication protocols. The actual physical SATA connection is what determines the speed. Not whether you are using IDE or AHCI. IDE and AHCI will preform the same because the SATA connection is the same speed regardless.

When you put it like that, it makes perfect sense of course. Besides, I didn't expect any miracles - though I would have thought that very-small-block writes would have sped up a little, but that does differ from system to system.

Curious, though, why so many then claim that "AHCI is faster than IDE." But this is exactly why I shared my findings to invite opinions. I have no problem at all with my numbers.

 

[GeneO]

ATTO is one of the worst benchmarks. It uses fully compressible data (all zeros). It also does not do many threaded small reads and writes (i.e. 64 thread 4k random reads.writes), where AHCI will perform much better than IDE

Arguably the best synthetic benchmark is AS_SSD.

Besides, from what I see of your posting, it looks like AHCI is slightly better

 

[Corazon]

Hmm.

I'll try AS-SSD again, then, but I had the impression ATTO was widely regarded as the best. Ahwell

Not sure what compressible data would have to do with anything, unless you're thinking Sandforce controllers and their built-in compression. My SSD uses an Indilink Martini controller.

 

[GeneO]

Hmm.

I'll try AS-SSD again, then, but I had the impression ATTO was widely regarded as the best. Ahwell

Not sure what compressible data would have to do with anything, unless you're thinking Sandforce controllers and their built-in compression. My SSD uses an Indilink Martini controller.

Only by vendors whose drives do compression so their rates look higher LOL

 

[fseal]

Actually on my system AHCI was gobs faster than IDE because, they do use different drivers. My IDE driver would not allow multithreaded reads/writes and the AHCI driver did. Speeding up the multithreaded 4k tests by /at least/ 10x.

But it is mainly about the additional features for new drives. If you had a good driver for a good sata chip in IDE mode then yes the differences would be minimal (and on a multi run test may average out to the same). But in some cases, due to using completely different drivers, the difference /can/ be night and day.

 

[DGLang]

I,ve posted this in other discussions, but since you do have a sincere question about speed variances, I'll post again.

I am giving three ATTO tests of my Patriot Pyro 60 GB SSD which I purchased for $109.xx.

This is a direct COPY of my system which was transferred from a regular HDD to the SSD. I am running WIN 7 PRO which enabled me to do the initialize and quick format of a partition which via 'disk management'.

The Built in WIN 7 disk management correctly aligns the first partion and all succeeding ones automatically for a SSD. I used my 'emergency restore' copy of acronis to simply copy my previously 'backed up' installation from the HDD to the SSD.

first, SSD as IDE no windows cache:

Second as AHCI no windows cache:

Finally as AHCI using windows cache:

 

[Corazon]

Sweet Lord, you're already making me feel slow with my SSD. LOL. Very impressive numbers (and differences), though.

fseal, thanks for the insight into driver/controller differences (which I suspected all along). I do wonder, though...currently I'm using the standard MSAHCI driver included in Windows 7. Since my motherboard has an Intel chipset/SATA controller, would I gain any noticeable advantage by installing the latest Intel storage drivers instead?

 

[OldMX]

Whats is that "using windows cache" option?

 

[DGLang]

That is the regular windows read and write cache. To get an exact representation of how a hard drive physically works, benchmarks are normally run with both the read and write cache disabled which forces the drive to do only actual physical reads/writes to the hard drive or SSD.

In the case of ATTO this accomplished by clicking on the direct I/O box in the atto control panel to enable or disable the windows cache during the test.

The reason for presenting the caches figures is that there has been several people asking how much difference it makes by enabling the write cache on the hard drives.

I was simply trying to present as much info as possible for others to consider in regards to the advantages of using the regular windows cache. Even though SSDs are very fast they still can not match the speed of regular on board Randon Access Memory (RAM) and if one is repeatedly reading the same blocks from memory, their entire system can be sped up by enlarging the cache if it currently is not large enough to keep the repeat reads in RAM.

In some older early versions of windows, it was also possible to enable/disable the read cache but that function is no longer available. The most one can do regarding the 'read' cache is to modify the vcache setting to change the amount of memory to dedicate to the cache.

 

[GeneO]

DG I think you are confusing two things. There is the operating system file cache, which resides in RAM, and there is write cache which is on-board the disk drive itself. These are two different beasts. Directio bypasses the operating system file cache and has nothing to do with the SSD write cache. Atto does have another option to bypass the drive's write cache, called "Force Write Access". The reason your the scores skyrocket with the directio unchecked is because yo are basically transferring to/from RAM, not the SSD.

Enabling the device write cache is generally not a good idea since on a power fail a file could get corrupted because it had not been completely written out to the disk even though the operating system thinks it has (part of it was in the write cache and lost during the power fail). The default for write cache is off for Windows 7 for this reason. Generally, SSDs have little to no write cache anyway.

 

[DGLang]

Windows does have both read and write caches, actually a SINGLE cache used for both purposes.

Due to the lack of on board cache on the early hard drives, the addition of the windows cache greatly improved first read speed and later write speed as well.

Hard disk drive manufacturers began adding their own on board cache to their drives once they saw how much windows cache helped..

Various manufacturers then began marketing hard drive controllers which contained on board memory to further improve windows performance. The additional cache on the controller GREATLY improved performance. I used to own such a controller whch I used on my early DOS and OS/2 machines. Even today some controllers have their own onboard cache to help them achieve their own best performance.

There was a fairly large demand for a caching controller from the people who's hard drives didn't have the onboard cache. It was much cheaper to add a cached controller which could handle multiple hard drives than to buy multiple additional hard drives with the onboard cache.

ATTO doesn't disable the physical hard drives' on board cache or any controller cache if present, it only bypasses the windows/system cache while it is doing the benchmarking. This is confirmed by the following snipette from ATTO regarding the 'direct IO' function.

'Direct I/O (test option)
If this option is checked, file I/O on the test drive is performed with no system buffering or caching. Combine this option with Overlapped I/O for maximum asynchronous performance.'

The system buffering or cache mentioned above IS the normal windows caching that I was talking about.

The reason for NOT disabling the hard drive's onboard cache during benchmarking is that if that cache was disabled, then any benchmark results would not accurately reflect the hard drive's performance under normal operating conditions.

 

[GeneO]

Windows does have both read and write caches, actually a SINGLE cache used for both purposes.


Hard disk drive manufacturers began adding their own on board cache to their drives once they saw how much windows cache helped..

Various manufacturers then began marketing hard drive controllers which contained on board memory to further improve windows performance. The additional cache on the controller GREATLY improved performance. I used to own such a controller which I used on my early DOS and OS/2 machines. Even today some controllers have their own on-board cache to help them achieve their own best performance.

The system buffering or cache mentioned above IS the normal windows caching that I was talking about.

The reason for NOT disabling the hard drive's on-board cache during benchmarking is that if that cache was disabled, then any benchmark results would not accurately reflect the hard drive's performance under normal operating conditions.

Well you did say disk write cache, not the system cache.

I am afraid even though you say a lot you do not understand the difference. The Windows 7 file cache caches files in RAM. It completely manages this cache and knows if any of it needs flushed to disk when a file is modified. When it flushes a file out of cache to disk or writes directly to disk, it expects that the data it wrote to the disk to actually be stored on the disk. When the disk driver returns from a write, the windows 7 system assumes it is on disk. This is very important to understand.

The file systems cache is there to improve performance to frequently accessed files and to be able to delay disk accesses so that they can be intelligently ordered for optimal performance. File performance for applications, even for writes, can appear enhanced as with your ATTO application. It has a completely different role than the disk's on-board buffer - it truly acts as a cache.

The on-board "write cache" on a disk drive is used to buffer data to reduce the latency of the disk. It is more properly referred to as a disk buffer, since it does not cache anything. It is truly a buffer between RAM and disk.

When a disk with a write buffer receives data from windows, it immediately returns a success to Windows once it is in the buffer, even though it is not on disk yet. At that point windows thinks it is safely on disk, but it isn't. If the power drops, then the data in the write buffer is lost and is never written to disk; even though Windows thinks it is there, it is not. This results in file corruption and is a reason you should not disable write-cache buffer flushing for a disk device unless it is backed up by a battery, like higher end raid controller's write buffer's are. Corruption like this can corrupt the whole file system, not just a file.

When write-cache buffer flushing is enabled for a disk (default), Windows, at critical points, instructs the disk drive to flush the data from the disk buffer to the disk immediately. It does this at critical points to ensure file system integrity. The best possible performance options without a battery backup is to enable "write cache" for the device, but leave write cache flushing enabled.

A disk's on-board buffer is also used as a read buffer and helps with read performance by reading ahead from the disk. The OS has no control over it (it is always enabled).

http://en.wikipedia.org/wiki/Disk_buffer#Read-ahead.2Fread-behind

If you use the AHCI driver for SATA disks, the drive can buffer writes and reads for optimal performance, but does not tell the operating system a queued write is successful until it is actually written to disk.

In short the operating system cache and disk buffer serve different purposes. The hard drive manufacturers didn't add on-board cache to emulate the operating system file cache.

 

[GeneO]

BTW I misspoke in a couple of posts above. I said Windows has write caching turned off by default. It is on by default. What is off by default is disabling write cache flushing.

 

[DGLang]

I fully know the difference between the 'systems' or 'windows' cache (same thing) and whatever cache may be on the hard drive.

The purpose of the orginal posting including the 'windows' or 'systems' cahe whatever you may call it is that I have seen a few postings in other threads on this message board by people asking if they should turn off the 'windows' or 'systems' cache because they thought it wasn't needed due to the SSDs being so fast.

My response was to show that yes indeed do leave the systems/windows cache turned on because it is STILL very helpful.

Obviously no manufactured 'performance test' can possibly totally accutately reflect what an INDIVIDUAL can expect from his system. At best it can only show what an 'average' user can expect while using his machine in the 'average' or most common manner, and to be truthful most power users don't use their machines in an average way due to overclocking and tweeking.

It is you who unfortunately missed what I was saying and you who intrepreted that I was referring to something other than the systems cache.

I wasn't going to mention this but for what it's worth, I have been working with mainframe computers since 1967. I have been working with PC's since before the IBM PS2 came out.

I have worked my way up through all of the computer oriented computer positions from control clerk in 1967 to systems engineer (higher than senior systems anlyst) back in 1992. I own my own consulting company, D G L Business Systems Inc, and among my many clients were Centel, Sprint, AT&T, and GTE. Companies I have worked for include CNA Insurance, International Harvester, Blue Cross/Blue Shield Association and others I can't even remember any more. I have been retired since Dec 2000.

I have built dozens of machines for friends, family and my clients as well as my clients employees.

It's not that I am confused about what I stated or why I stated it, it's simply that you misunderstood what I was trying to say.