Slashdot Mirror

← Back to Stories (view on slashdot.org)

Performance Showdown - SSDs vs. HDDs

Posted by timothy on from the all-those-Ds-at-once dept.

Lucas123 writes "Computerworld compared four disks, two popular solid state drives and two Seagate mechanical drives, for read/write performance, bootup speed, CPU utilization and other metrics. The question asked by the reviewer is whether it's worth spending an additional $550 for a SSD in your PC/laptop or to plunk down the extra $1,300 for an SSD-equipped MacBook Air? The answer is a resounding No. From the story: "Neither of the SSDs fared very well when having data copied to them. Crucial (SSD) needed 243 seconds and Ridata (SSD) took 264.5 seconds. The Momentus and Barracuda hard drives shaved nearly a full minute from those times at 185 seconds. In the other direction, copying the data from the drives, Crucial sprinted ahead at 130.7 seconds, but the mechanical Momentus drive wasn't far behind at 144.7 seconds."

16 of 259 comments (clear)

  1. bad test by Werrismys · · Score: 5, Insightful

    In typical use most of the time is spent seeking, not just reading or writing sequential blocks. The Windows XP disk IO is especially brain damaged in this regard (does not even try to order or prioritize disk I/O). Copying DVD images from one drive another is not typical use case.

    --
    'Once scientists, even the dim-witted social scientists, get muzzled, the Western Civilization is finished.' - oldhack
    1. Re:bad test by SanityInAnarchy · · Score: 4, Interesting

      Consider, also, that when you're doing anything other than the contrived "copy from one device to another"... HD-DVD has a minimum guaranteed throughput of something like 30 mbits, Blu-Ray needs 50. It looks like the worst numbers on the solid state devices were still at least some 30 megabytes per second, meaning you could play five Blu-Ray movies at once.

      Skimming the article, it seems very likely that the person responsible has read just enough to be dangerous (they know the physics of why seeking is slow), but not enough to have a clue what kind of behavior would trigger seeking. The one measure was boot time, during which they acknowledge that Vista does a bunch of background stuff after boot, but don't measure it.

      He did get one thing right, though -- they are not exactly living up to their potential. For one thing, there are filesystems explicitly designed for flash media, but you need to actually access it as flash (and the filesystem does its own wear leveling) -- these things pretend to be a hard disk, and are running filesystems optimized for a hard disk, so the results are not going to be at all what they could be.

      --
      Don't thank God, thank a doctor!
    2. Re:bad test by ThePhilips · · Score: 4, Interesting

      XP IO subsystem is pretty OK.

      The problem with SSD is that flash based storage has much much higher block size.

      While conventional HDDs have block size 512 bytes, actual SSDs have block size of 64 kilobytes.

      Not only Flashes write relatively slow, but if file system has e.g. cluster size of 8K, every write to it in worst case would also (re)write redundantly 64K-8K=56K.

      Test is realistic - if you want to see how bad most applications can be with SSDs. But that's going to change with SSD becoming more and more common place.

      If they really wanted to test SSD performance they would have taken Linux with jffs2 or newer logfs. Though this two have their own problems.

      --
      All hope abandon ye who enter here.
  2. Untested performance... by smitty97 · · Score: 4, Interesting

    Unfortunately there's no comparisons of battery life and speed tests with fragmented files.

    --
    mod me funny
    1. Re:Untested performance... by Ethanol-fueled · · Score: 3, Interesting

      ...And the picture won't be complete until we have real-world failure data for the solid-state drives.

  3. Not very good reasons... by MrKevvy · · Score: 4, Insightful

    Computerworld compared four disks, two popular solid state drives and two Seagate mechanical drives, for read/write performance, bootup speed, CPU utilization and other metrics.

    But of course not the metrics that really matter, which SSD's vastly excel at and make them worth the price for many people: MTBF, power consumption, ruggedness and noise level.

    --
    -- Insert witty one-liner here. --
    1. Re:Not very good reasons... by Mordok-DestroyerOfWo · · Score: 5, Insightful

      If I remember correctly the first LCD monitors were exorbitantly expensive and couldn't hold a candle to their CRT brothers. But since they saved so much space and energy, within a few years those problems vanished. I'd say it's still too early to close the books on SSDs.

      I know it's not a car analogy, I humbly beg the forgiveness of the /. community.

      --
      "Never let your sense of morals prevent you from doing what is right" - Salvor Hardin
  4. Power Consumption by Ironsides · · Score: 3, Insightful

    Too bad he didn't include power consumption. If I'm going to use an SSD for anytime soon, it will be in a laptop where power is my key concern. Performance is more of a desktop/high end issue right now.

    --
    Fly me to the moon Let me sing among those stars Let me see what spring is like On jupiter and mars
  5. Why a "drive"? by Ossifer · · Score: 3, Interesting

    Am I the only one questioning why these devices are implemented using a mechanical drive interface? Maybe it's a negligible cost, but to me it would seem that a memory bus optimized for flash memory would be a better way to go, than trying to piggy-back a mechanical drive's bus. How much faster could these be if their existence was planned into, say Intel's chipsets?

    1. Re:Why a "drive"? by Alioth · · Score: 3, Informative

      Well, the IDE bus isn't mechanically oriented anyway - we don't actually use cylinders, heads and sectors (and haven't for years), we use block addressing and the drive electronics has figured out how to move the mechanics. Block addressing isn't all that far off from addressing an individual byte in memory anyway - except you're addressing a whole block rather than a single byte (and for mass storage, whether it's mechanical or flash, you're going to want to do it that way so you don't have an absurdly wide address bus). Parallel ATA uses a 16 bit wide data bus.

      --
      Oolite: Elite-like game. For Mac, Linux and Windows
  6. Stupid Test by phantomcircuit · · Score: 4, Informative

    They only tested burst speeds, there was no random access testing.

    SSD works best when accessing files randomly.

  7. SSDs are ideal for servers by ncw · · Score: 4, Insightful

    As any sysadmin knows, on a busy server what creams the disk isn't Megabytes per second, it is IO transactions per second.

    According to the article the Crucial SSD has an access time of 0.4 ms which equates to 2500 IOs/s as compared to the Barracuda HDD with 13.4 ms access time which equates to a mere 75 IOs/s.

    So for servers SSDs are 33 times better!

    Bring them on ;-)

    --
    Every man for himself, all in favour say "I"
  8. Seek Times Make the Difference by pancrace · · Score: 5, Interesting

    We installed one of these for processing millions of small, read-only database transactions. The database only gets written once a day, but is too big for efficient cacheing. Even with a U320 15k drive we were still suffering, only being able to run about 700/min. With a flash drive, we're running over 25,000/min, peaking at 50,000/min. But the weekly copy of the database takes about 20 minutes, vs the 3 or 4 minutes it used to take.

    - p

    --
    I don't have a .sig
  9. Re:Performance is not the key to SSD by Sancho · · Score: 3, Insightful

    http://www.appleinsider.com/articles/08/02/07/macbook_air_hdd_and_ssd_battery_benchmarks.html indicates that the battery usage (at least compared to the HDD shipped with the Macbook Air) is negligible. No moving parts is nice, though manufacturers have addressed some of the ruggedness issues by including drop sensors. Actual, real world wear hasn't had a chance to surface yet--I'll definitely be curious to find out if SSDs live up to the speculation.

  10. How Flash SSDs Work and How They Can Work Better by DDumitru · · Score: 3, Informative

    My apologies for a long post. There will be some adverts embedded, but I will try to keep things informative.

    The reason that Flash SSDs act "wierd" in benchmarks is that they have asymmetric performance patterns when reading and writing. Particularly with random operations, this asymmetry is huge. Here are a couple of example "drives":

    * Mtron 7000 series: >14,000 4K random reads. ~130 4K random writes.
    * SanDisk 5000 series: ~7,000 4K random reads. 13 4K random writes.
    * Cheap CF card or USB stick: ~2,500 4K random reads. 3.3 4K random writes.

    This is a 100:1 performance deficit when doing random writes versus the random reads. This has some really weird impacts on system performance. For example, if you run Outlook and tell it to "index" your system, it will build a 1-4 GB index file in-place with 100% random writes. If you do this on a hard disk, the job takes a long time and drags down your laptop, but the operation is still pretty smooth. Do the same think on an SSD and the system slugs to molasses. One of our customers described it as "totally unusable" with 2+ minutes to bring up task manager. What happens is that the fast reads allow the application to dirty write buffer faster and this then swamps system RAM, you get a 100+ deep write queue (at 13/sec), and you want to throw the machine off of a bridge.

    This fix as some have described it is not some magic new controller glue or putting the flash closer to the CPU. It is organizing the write patterns to more closely match what the Flash chips are good at. Numerous embedded file systems like JFFS do this, but they are really designed for very small devices and are more concerned with wear and lifespan issue than performance.

    Now here comes the advert (flames welcome). A little over 2 years ago, I wrote a "block translation" layer for use with Flash storage devices. It is somewhat similar to a LogFS, but it is not really a file system and it does not play be all of the rules of a LogFS. It does however remap blocks and linearize writes. Thus it plays well with Flash. It also appears to be an "invention", and thus my patent lawyer is well paid.

    The working name of the driver layer itself is "Fast Block Device" (fbd) and the marketing name is "Manged Flash Technology". And what this does is to transparently map one block device into another view. You can then put whatever file system you want into the mix.

    In terms of performance, it is all about bandwidth. Build a little raid-5 array with 4 Mtron drives and you will get over 200 MB/sec of sustained write throughput. With MFT in place, this directly translates into 50,000 4K random writes/sec. Even better, you tend to end up with something that is much closer to symmetric in terms of random read/write performance.

    MFT is production on Linux (it has actually been shipping since last summer) and is in Beta test on Windows. It works with single drives as well as small to medium sized arrays. It does work with large arrays, but the controllers don't tend to keep up with the drives, so large arrays are useful for capacity but don't really help performance a lot. Once you get to 50,000 IOPS it is hard for the controllers to go much faster.

    Consumer testing with MFT tends to produce some laughable results. We ran PCMark05's disk test on it and produced numbers in the 250K range. This was with a single Mtron 3025. Our code is fast, but we fooled the benchmark in this case.

    There are several white papers on MFT posted in the news link of our website:

        http://managedflash.com/

    My apologies for the advert, but I see a lot of talk about SSDs without actually knowing what is going on inside.

    I am happy to answer any questions on-line of off.

    Doug Dumitru
    EasyCo LLC
    610 237-2000 x43
    http://easyco.com/
    http://managedflash.com/
    http://mtron.easyco.com/

  11. Re:And some drop tests, and airport scaner tests, by CommanderData · · Score: 3, Informative

    Well, I can supply my own experiences for you, after using a 32GB Samsung SSD for a year, and a 64GB Samsung SSD for several months...

    1) Mine have been formatted NTFS, running Windows XP (and additionally Apple HFS Journaled recently when experimenting with OS X). I do not defragment the SSD, there is no point. Read speeds have always been better than write speed, but I see no difference in performance over time.
    2) Both of the drives I have are fully functional, even though I abused the 32GB one mercilessly. That laptop has only 1GB of RAM and I would run so many programs that things were swapping constantly for the past year.
    3) The 32GB SSD has been through airport scanners approximately 50 times now, no problems. The 64GB is too new, only travelled a few times so far.
    4) My laptops are always on the go, brought into many factories as a consultant. While in my bag it has taken falls down sets of stairs. The laptop itself (a Fujitsu P1610) has been dropped from a height of 3.5 to 4 feet onto a metal catwalk while running with no adverse affects (other than a few scuffs and dents on the corners).
    5) Not sure how well they stand up to static, but it has stood up well to a variety of high EM fields, and high/low temperatures. No data loss. I have had regular hard disks die from working next to large transformers (and their magnetic fields) for an afternoon.

    Hope that helps you. For my line of work, they have been incredible. I used to go through 3 or 4 laptop hard disks per year due to various issues. Now the only reason I bought the 64GB SSD is increased storage capacity.

    --
    Urge to post... fading... fading... RISING!... fading... fading... gone.