Reviews > Storage > Hard Disks & Co. > CSX Compustocx SSD 30GB: MLC & SLC > Test system, procedure & benchmarks

Test system, test procedure & benchmarks used


Test system

  • Intel Core 2 Duo E2180 65nm at 3 GHz
  • Spire Bluestar 1000
  • XFX nVidia 780i SLI at 333 MHz FSB
  • 2x1024 MB Qimonda CL5-5-5-15-1T at 333 MHz
  • Paging file size: 1024 MB
  • XFX 8600GTS 256MB PCIe


  • Western Digital Caviar Blue 3.5" 320GB SATA II (WD3200AAKS)
  • CSX 2.5" 30GB SATA II (SSDQ-SATA2-SLC-30)
  • CSX 2.5" 30GB SATA II (SSDQ-SATA2-MLC-30)
  • Western Digital Scorpio 2.5" 160GB SATA I (WD1600BEVS)


  • Amacrox FreeStyle 750W
  • Windows Vista Home Premium 64bit



Test procedure

To get a picture of the performance of our candidates, we decided to use a colourful mix of different benchmarks and applications. This way, we try to offer our readers both the common benchmark results and the “real” performance as you would experience it in everyday usage.

Furthermore, temperatures in relation to the ambient (room) temperature and power consumption, taken directly from the cable plugged into the drives, are shown in graphs. But first of all, let us have a closer look at our tests, what they do, how they do it. Some of our tests (mainly writing speed tests) have been started from a second disk, so that the cadidate was not the system drive.


Benchmarks

Some of the benches have been done up to 10 times in order to ensure we get one quite accurate value out of many rather inaccurate numbers. The following benchmarks have been used:


  • HD Tach 3.0.4.0 (simplisoftware.com)
    Established and well-known, comparative benchmark to check the pure writing speed, run cache-burst-tests and get the average access times. Write tests are not offered.

    >>> throughput rate and burst-speed: the more the merrier
    <<< access time: low is what you want




    Nothing you wouldn't have expected: Since SSDs don't rely on spinning platters, neither on a quickly reacting write/read-head, their access times are outstanding. Looking at the transer rates however reveals, the CSX SSDs can't win with a big clearance – yet, they win against one of the best performers from the desktop segment. To sum it up: These screenshots show us why SSDs are famous for their access times – it is almost not existent. Their reading performance is good too. In other words: No notebook-HDD would stand the slightest chance, only the fastest desktop-HDDs can compete.


  • Adobe Photoshop Benchmark (retouchartists.com)
    This batch file is pretty intense and uses all of the physical memory it can get plus makes heavy use of the data storage medium on top of that. The jpeg-picture used has the size of 700kB and a resolution of 2500x1667px. This benchmark counts the seconds it takes the computer to manipulate the image.

    <<< lower is better
    Photoshop is the program when it comes to professional image manipulation. And playing with pixels can be a pretty time intense thing. The CSX drives do a good job, still, we don't feel overwhelmed by their speed. What made us smile instead was the moment after the benchmark session: While the magnetic disk took several minutes tidying up the data mess from this test, the Solid State Drive didn't mind clearing the memory within a blink of an eye and responded as if we just had booted the system – point for the SSD!



  • PCMark Vantage 64bit HDD-Suite (futuremark.com)
    The newest and traditionally disputed system benchmark from Futuremark offers a variety of tests which, amongst others, also examine HDD / SSD performance. We exposed the interesting part of it, namely the HDD Suite:

    >>> higher is better

    total pointsHDD-Suite
    • 4624 - WD 3.5" Caviar
    • 9470 - CSX 2.5" SLC
    • 8908 - CSX 2.5" MLC
    • 2709 - WD 2.5" Scorpio

    The total points comparison attest SSDs double the performance of standard HDDs. But far more interesting than this is the fact that they get an A for reading, a F for writing. From this it follows that if you use write-intense applications, your SSD won't perform any better than the slowest notebook-HDD - and desktop-HDDs show the ropes to the flash-memory-conglomerate.


  • RAR compression and decompression
    In this benchmark we pack and unpack files different in size, together about as big as 150MB.
    The time needed to process this task is measured in seconds.

    <<< the shorter the bar, the better
    While the time saving with HDDs is neglectable for compression, it gets bigger at decompression. Once again, SSDs show their weakness in writing.


  • FC-Test (xbitlabs.com)
    This simple buf effective tool creates files of any size that can then be used in copy benchmarks. We decided to use the install- and ISO-patterns. We shift each from both a to b on just our test drive ( 0->0), and from a secondary drive onto our test drive (1->0) . Install simulates a collection of 414 small and big files which weigh altogether ~575 MB. ISO contains three big files, each single one as big as a casual CD – makes ~1,6 GB. The time needed to copy these files will give us some information about the drive's handling with small and big files.

    <<< less is better
    The first benchmark of practical character tells us clearly what's happening: Regardless of whether the file is copied onto the same drive or from drive 0 to 1, the good old HDD (particularly the 3.5” family) overruns the SSDs mercilessly.


  • Atto Disk Benchmark (Download techpowerup.com)
    Another benchmark to check out the read- and write-performance of storage devices. The fact that the values are far too high doesn't really matter if used for the purpose of comparison.

    >>> higher is better


    Once again: This benchmark is good for illustration purposes only, the values shown are far away from reality. We can't even compare the outcome due to the lack of transparent numbers. So we just leave you with the screenshot.


  • HD Tune Pro Lese- und Schreibleistung (hdtune.com)
    An alternative to HD Tach, which also allows to run write-benchmarks. All average transferrates for both read- and write-processes are captured and listed in MB/s, furthermore the program states the accesstimes in ms.

    >>> transferrate und burst-speed: higher is better
    <<< accesstime: low is good, lower even better

 




    Usually a pretty accurate and meaningful benchmark, HD Tune failed this test and didn't get the accesstimes right. As has been proved before, these values should be much higher for SSDs and especially higher when compared to their HDD-brothers.


  • h2benchw 3.12 (heise.de)
    h2benchw is an application without a GUI (graphical user interface), which runs via command line. It does a decent job detecting the real performance of a drive / disk accurately. Normal tests already take longer than one hour, even for small drives. We want to see the full show and got both the transferrates and the accesstimes as average values, measured all over the disks / drives (due to the mechanical characteristics of HDDs, their performance differs depending on where on the platters data is written to or read from).

    >>> transferrate: higher is better
    <<< accesstime: lower is better
     
    A popular and on top of that one of the most trusted storage medium-benchmarks at all. If you ask us, this piece of software gives you a very accurate impression of how our reviewed SSDs perform. Write-access takes as long or longer, reading-performance is nearly the same; just the extremely short read-access time is an advantage that accelerates work.


  • Sisoft Sandra ( sisoftware.net)
    Another well-known benchmark which allows the user to bench pretty much every component of the computer. We were mainly interested in the transferrates (MB/s), read- and write-accesstimes of our HDDs/SSDs.

    >>> transferrates: high numbers is what you're after
    <<< accesstimes: the lower the better
    What we have here is not very meaningful. Enjoy the picture anyways!


  • Everest Disk Benchmark Suites (lavalys.com)
    What many people know is that Everest can test your RAM and processor. Only few know it also offers to check out the disk/drive installed. We ran the benches and jotted the transferrates (MB/s) as well as the accesstimes – once again, we know...

    >>> transferrates: guess...higher is better!
    <<< Zugriffszeiten: the lower the faster

Everest shows us what we already knew from our h2benchw results: SSDs are bloody good readers, but really bad writers. What did we expect?

When Thetis tried to make her son Achilles invulnerable by dipping him into the waters of Styx (the river of Hades / the underworld), she forgot to also water his heel, where she was holding him. Those of you who are into Greek Mythology (or Brad Pitt) know the outcome: Achilles fought many glorious battles and was finally defeated by Paris, who shot an arrow into his heel. Now, SSD manufacturers acted like Thetis and SSDs vital spot is their writing speed. They may win every benchmark, but whenever writing is important, they perform badly (SLC) or even terribly (MLC). But where does this lack in speed originate from? Obviously, the write-latency has to do with it. But is that all?

Very often you will get to hear: “SLC-memory is 300% faster at reading and a mere 40% faster at writing than MLC, cause the cells have to deal with one bit only.” Well, unfortunately the truth is a bit more complex. First of all, putting two bits into one cell is much more efficient cause it results in a higher density of data. Following from this, SLC-SSDs should be slower at reading and writing. But as we know from our small (sorry...) tech-excursus, this is not the way it is. Since MLC-memory is a fair bit more complex than SLC-memory is, they have to have a better error-correction (ECC), which in turn takes a lot of time. Whenever something is written on the drive, a so called “flush command” makes sure the electrons have really been locked away in their cells. If this is not the case, the whole write command needs to be repeated. “Yes, but SLC-SSDs have to do this, too”, could be your answer. Right, you've got a point here. However, if you consider the 4 NOPs and the fact that SLC uses 1 Bit per 512 Bytes and MLC 4 Bit per 512 Bytes for ECC, you will agree that MLCs are a) slower in rewriting the block, b) more vulnerable to errors; or why would they use 400% more space for ECC than SLC-technology does? There you go... Another small contribution to the big write-latency is the erase latency, which is 1,5ms higher for MLC. Okay okay, this is really just a tiny summand, but here's a better one: The size of erase blocks. MLCs are usually put into bigger groups than SLCs. You know what that means, don't you? If not, just go back to the tech-excursus. Our last argument for the high write-latency of a MLC-SSD has once again to do with the controller. The manufacturers themselves point out that wear leveling is extremely complex, even more so for MLC-SSDs. Reading this and thinking of the missing “log structured file system” and a cache, you get the impression that the controllers used nowadays aren't really capable of controling a SSD.

As you can see, there are reasons for such a high write-latency MLC-SSDs are suffering from. And they are definitely more plausible than all these standard comments.
Now we know what makes MLC-memory such a slow writer. But how about SLC-memory, which is still much slower than a HDD? Here also, we can point to the controller as well as the erase-characteristic of NAND-Flash-technology.
To conclude, we would like to let you know that none of the OS on the markets is made for the operation with SSDs. The controllers have to emulate a HDD, which can take a lot of time. Linux users probably know this from Cedega or Wine...(We don't say programs are always slower, but they can be!)...

Measurings concerning the power consumption and temperatures of our test sample can be found on the page.