SandForce: HD-Tune Speed

Although HD-Tune is a single-threaded application that cannot offer deep queue depth, it does offer a basic interpretation of linear bandwidth speed. Despite the limitations, we've included this test to provide an additional perspective into our research.

Using a clean and conditioned ADATA S599 Solid State Drive, bandwidth speed tests were conducted on the SandForce SF-1200 SSD controller using HD-Tune 4.01:

Comments

There appears to be a flaw in the Microsoft AHCI driver, large secondary hard drives (ex. 1TB) will disappear after the computer enters sleep mode. Installing the Intel RST driver 9.6 driver has solved the problem for a number of people including me.

For those who have asked: I do not presently have any plans to add more tests of other SSDs into this article. The primary purpose was to illustrate the differences seen between AHCI and IDE, and not necessarily demonstrating the differences for every SSD controller. I didn't include Fusion-IO, RunCore, Micron, Toshiba, Marvell, Intel, Mtron, MemoRight, or PhotoFast... to name a few.

Thank you for providing a comprehensive, informative, and useful article on SSD performance and testing. Although not the articles intent, I imagine SSD owners that cannot use them in AHCI mode will be pleased (relieved!) to see that SSD performance is not terribly compromised (IMO)in IDE mode. I don't understand why SSD manufactures have not offered any utilities that provide at least some of the information available in the testing software you used. I tried AS SSD Benchmark, and was pleased to verify (my first SSD) I am running in AHCI mode, my SSD's alignment is correct, and my scores were great relative to the data you provided in this and other SSD articles. In contrast to that, my SSD's manufacture has provided virtually no useful information or ways to get it. Thanks again and keep up the good work!

Well I experienced a 30-40MB jump in speed over IDE. Using a OCZ Vertex 2 60GB. I was already getting 230MB/s read and write, with buffered being slower if you can imagine. That jumped to 270MB/s when I went to AHCI, under sisoft. I didn't even have to run a bench to notice the difference. On bootup, win 7 didn't even get halfway through the logo animation before it reached the desktop. I'll have to run another test using file cache.

You focus on speed rather then access-time. I can assure you that the difference between 1ms (IDE) over 2ms (AHCI) has a far greater impact then the few kilobytes you gain in speed.Ever tested SCSI versus SATA at the same RPM? Well there you will see exactly the benefit of access-times. Speed is rubbish when AT isn't good.Test controllers on AT first, speed second, the picture will be a lot different in favor of IDE mode.Same as with Internet, band-weight is nice, but if your ping is crap it won't be fast either.You focus on the wrong points to measure a drive.

The Ship IOPS / Bandwith analogy is just wrong.it would be more like:IOPS is the ship's speed, Bandwith is the cargo capacity.Why:If you want to build a small house, and you need parts that can be delivered by either:1x Big slow ship, that has 100x the capacity requiredor1x Small fast ship, that has just the capacity required

you'll be able to start building your house sooner with the fast ship, as it will arrive sooner.

As you also have access-time, that one determines how close the cars can run behind each other.The lower the number the closer they can drive behind each other, also affecting the IOPS.As such access-time is the most important number over all of them.

Do you know how important access-time really is? What you are saying now is rubbish.IOPS can not be fast if your access-time is slow.The access-time is the time the device needs to find the data and start delivering it.There is no way on earth your IOPS can be high with a low access-time.Sorry Olin, but you better find a new job if you don't understand the importance of access-time.And yes I have read your article, and it's way too much focused on band-weight.Typical mistake, why do you think SCSI drives are twice as fast as the fastest IDE drive at the same RMP and band-weight? Exactly, it's the low access-time that causes this...not throughput.Because of your wrong interpretation of access-time, I consider your entire article and conclusion as useless for anybody.Do research on the matter, you will find I'm right.Your IOPS versus Access-time is completely wrong.IOPS means I/O operations per second, if your access-time is low it means it will do LESS I/O operations per second as it needs to wait for the device to access the data.Do your research before writing rubbish as you make a fool of yourself.

So in your heavily opinionated assessment, a SSD with relatively high access time cannot offer high IOPS? Explain how SandForce was able to offer a SSD with the same access times, but dramatically different IOPS. Also, do the math of my figure above.

Bas, the only person making a fool of himself is you. Not only is your argument faulty (the data is right here in this article ... ) - your tone is that of an agitated 12 year old. Learn to control yourself and conduct proper research.

I see alont of SSD reviews, but they all reference Intel Platforms and Intel Drivers etc...It would be nice to see some Tests/Reviews of Benchmarks that provided results for both camps ( Intel & AMD )I would also be appreciative to see Microsofts AHCI Driver tested/included as well as AMD's ATI AHCI Driver tested/included. As well as the Marvell AHCI driver that is more commonly seen in AMD platforms verses what shows up or is seen in the Intel Platforms.....

Thanks for this review, but it is hard to apply what I have read to my AMD Platform which uses ATI AHCI Drivers &/or Microsoft AHCI Drivers if I use the MS Windows 7 generic AHCI driver......

Both bas and olin have missed the mark here by trying to oversimplify the issues. There is no direct one-to-one relationship between or among IOPS, access time, and bandwidth. Too many factors intrude for such simple relationships. For truly independent IO's, access time can put an upper limit on IOPS, but more than a small percentage of IO's are logically and physically dependent. Depending on the intelligence of the drive and OS software in dealing with various forms of IO, huge differences in performance can arise. Depending on the page and block saturation in an SSD, writing the same file to that device can produce vastly different results, even in the absence pf interfering or block overlapping IO. Different fill methods for blocks and pages can cause what appear to be random changes in performance. Even in the simplest of cases with known algorithms, understanding these performance fluctuations can be complex.

If you would like to push a drive to the maximum performance in a real world situation, you should put a single large paging file on the drive and use programs that drive the paging rate as high as possible. When that settles down to a constant rate over time, then a measurement of paging rate will tell you what the maximum performance is in a real world situation. I am not sure that TRIM will actually improve performance in a busy drive, and it certainly loses the ability to recover any deleted file. A smart TRIM handling on a drive would queue the TRIM requests up and satisfy them when the drive is not otherwise busy, rather than giving them the priority they have under existing classification. TRIM could certainly help in a situation where the read to write ratio is high and the drive is not particularly busy, but this also would lessen the advantage the SSD has over a drive with a large built-in cache.

#bas and olin are both incorrect continued —
rarchimedes2011-11-04 15:17

Unfortunately, we do not have a good way other than thruput to measure actual physical transfer rate. Normally, transfer time plus access time would determine the actual IOPS for any particular type and size of file, but SSD's are so extremely sensitive to page and block alignment on IO's that characterizing such beyond the simple, fully erased situation is basically impossible. The one thing that I will agree with bas on is that the tests in this review are not particularly meaningful. I'm not sure that even the relative difference between IDE and AHCI has much meaning. It is going to take some very intensive testing with some experimental software, specifically designed to test the devices in a consisten and repeatable manner that is more closely related to the real world to produce any meaningful comparisons of anything.

Where am I wrong? AHCI adds commands to the protocol that are rubbish, like NCQ.There is no point in doing NCQ as there is no rotation of the drive where command ordering is needed or even wanted.NCQ has been proven to hinder the performance as it can stall the controller by making the computer WAIT before giving new commands.SSD is a matrix and ordering is silly as all cells deliver data at the same speed, there is no ordering wanted to optimise the rotations in where data can be read.But AHCI is still doing it, as such it lowers performance, and this can be noticed when using better benchmarks that can do proper I/O reading and writing combined with multiple commands at the same time. That benchmark has been here for ages, called ATTO.Give ATTO a high command-que depth and see what happens, it will show the difference. As ATTO gives read and write speeds, for me it's the best harddisk/ssd benchmark on the planet when used properly.Meaning VERY large Block-size and high Que-depth, then it gives pretty accurate numbers.

That would be your 'build one house' analogy...That's only applicable in a single-threaded system.Your modern PC is more akin to a large downtown reconstruction effort after Catrina...

Also, comparing the HDD with a big cargo ship...On a large cargoship, unless your goods are all in one container, or all the containers with your goods have all been stacked on top of each other, they will need to unload some containers inbetween yours. Then probably reload the inbetween containers.

A better analogy would be a long freight-train carrying cargo containers that passes under a single crane that can lift containers off the wagons.What is more effective?1. Unloading the containers belonging to one customer(1, 15, 33, 7 - the last one was a recent addition that was fitted there after container 7 was removed on an earlier stop), then the next customer(4, 8, 12, 13, 14, 53)?". Or to offload them in a sequential order?

Remember, the crane can only offload containers at a fixed speed, the train can only be moved forward or back at a low accelleration...

To add to Bas info--for those desktop users that use their computers for other things other than as internet servers, like burning CDs and DVDs etc...IDE mode for SATA controllers offers vastly improved CD/DVD writing performance. In AHCI mode my DVD burners do not seem to work properly when attempting to write. In IDE mode my DVD burners operate as they should. Until they perfect AHCI mode for other peripherals such as DVD burners on the SATA controller, I am sticking with IDE mode. There's not enough performance difference between IDE and AHCI to warrant putting up with the quirky DVD burner behavior in AHCI mode. Nuff said! If you run SATA burners and still like AHCI over IDE, then I've got some swamp land in Florida I'd like to sell you.

Gigabyte 990FXA-UD3Vertex 3 120gb SSDWD 1.5tb SATA2DVD/CD RWA recent BIOS update added VRM MOS protection.This disables access to the BIOS settings during POST .If the Windows 7 based TouchBIOS utility is used, and the SATA type is changed from IDE to AHCI in CMOS and the system is rebooted. Windows renames the Boot drive from C:\ to E:\ and Windows Blue Screens during loading. Normally this wouldn't be a big problem, since the BIOS setting could be changed during POST. However, the VRM MOS protection forbids changing those settings during POST. The BIOS must be reflashed with a legacy BIOS (F6) or earlier, that does not have VRM MOS protection, in order to enable the IDE type support that Windows was installed with. I believe this VRM MOS protection is a standard part of the new types of BIOS required by Windows 8. So it must be enabled during OS installation or it could be lost