Are SSDs Finally Worth the Money? 405
Lucas123 writes "The price of 2.5-in solid state drives have dropped by 3X in three years, making many of the most popular models less than $1 per gigabyte or about 74 cents per gig. Hybrid drives, which include a small amount of NAND flash cache alongside spinning disk, in contrast have reached near price parity with hard drives that hover around the .23 cents per gig. While HDDs cannot compare to SSDs in terms of IOPS generated when used in a storage array or server, it's debatable whether they offer performance increases in a laptop significant enough that justify paying three times as much compared with a high-end a hard drive or a hybrid drive. For example, an Intel 520 Series SSD has a max sequential read speed of 456MB/sec compared to a WD Black's 122MB/sec. The SSD boots up in 9 seconds compared to the HDD's 21 seconds and the hybrid drive's 12-second time. So the question becomes, should you pay three times as much for an SSD for twice the performance, or almost the same speeds when compared to a hybrid drive?"
Re:Not sure if you can post anonymously early or n (Score:2, Interesting)
Great, first post but only because I noticed a hole in the latest revision of the system.
And I'm not sure it's a hole. Would it have still allowed me to post without the post anonymously box?
And the actual question still stands- is the memory/storage paradigm just traditional at this point, or is it still useful?
Re:In a laptop performance isn't the only issue (Score:5, Interesting)
Bingo - drop survivability and heat generation. These are two of the best reasons to use SSD in a laptop, and not HDD. Nothing to do with performance.
They've been worth it for a while now (Score:5, Interesting)
Seriously? (Score:5, Interesting)
For a serious computer user, an SSD has been worth the money for a while now.
* If you need to do serious disk I/O with a mid-size or smaller notebook, RAID isn't even an option for increasing speed.
* Running multiple virtual machines? Want them to boot quickly? An SSD makes them feel native.
* Running Windows as a native operating system, and have more than one or two programs that you legitimately want to launch at boot, and can't/won't disable? An SSD makes your computer usable within tens of seconds as opposed to multiple minutes.
* Doing compilation? Syncing of filesystems with a system such as Unison? Doing anything filesystem heavy? The speedup is insanely awesome.
If all you care about is running Your Web Browser and editing Word documents, or storing a few photos, obviously an SSD is a more questionable upgrade, and probably will be for the foreseeable future.
Re:In a laptop performance isn't the only issue (Score:5, Interesting)
One interesting side effect of having a legitimately fast SSD is even though you save power power on not spinning a platter around you can end up using that power (or more) with increased CPU usage. Ex: Semi-Random reads from mechanical drive might be pulling data ~40MB/sec on a good day... the CPU doesn't have a lot to process at once or just does in chunks so all that nice power saving tech comes into play (reduced clock or cores or what have you). Now, pop an SSD in and start getting 300-500MB+ semi-random read speeds and your CPU will find itself a hell of a lot more busy having to actually process all of that.
It's a good "problem" to have, if you can even call it a problem ;)
For how long? (Score:3, Interesting)
An item yet unmentioned at the time I post this, is SSD lifetime. The are finite, you know, and probably a lot more finite than a well-protected HDD. The manufacturer states the number of write operations the storage cells can take on average before going kaput, and its up to the controller & OS to "age" them all equally to ensure maximum longevity (thanks, TRIM). This and speed are the main determinants of the cost of the devices and the differentiator between user and server-grade SSDs.
Nowadays with shady outfits jumping onto the SSD bandwagon, we'll see really crappy devices made from rejected storage chips hitting the markets, which will fail prematurely and give the technology a bad rep.
Re:Not sure if you can post anonymously early or n (Score:5, Interesting)
The cloud isn't nearly fast enough or cheap enough to replace any sort of local storage. That's not even getting into the obvious question of reliability and availability that so many people like to just gloss over.
Re:Not sure if you can post anonymously early or n (Score:4, Interesting)
I smell FUD, and that's kinda bad in view of the power consumption figures being explicitly stated in *easily* publicly available datasheets
Let's see how much supply current is needed to self-refresh a 1 terabyte of DDR3L SDRAM.
Let's look at 8 gigabits MT41K1G4 [micron.com] chips from Micron. The chip takes 28mA max at 1.35V. That is 37.8mW per 8 gigabits. A terabyte has 8000 gigabits, or 1000x as much -- that's 38W or about as much cooling as a CPU found in someone's desktop PC might dissipate.
If powering and cooling one CPU is "substantial power supply and cooling", then, well, obviously we've got different points of view on this stuff.
Do notice that those chips dissipate more power only if you access them, so 38W is the idle state but even if you *do* access them, you don't dissipate all that much more -- you'll be probably only accessing a couple of chips at a time. The worst case all banks interleaved read current on those chips is 320mA, so if you access 4 chips at a time, that's still only 1.8W of extra power on top of refresh power.
Of course the logic used to piece together all the chips into a storage device will also use up power, but that logic is in idle low-power state when the chips are not being accessed, so it's a big deal.
Benefit, ROI: yes (Score:5, Interesting)
I actually ran the numbers on this for my company. Based on average usage on our standard laptop image and typical employee salary:
$1.82 saved in salary time per bootup (assume one bootup per day)
$2.23 saved in salary time per day due to files opened/programs launched
That's $4.05/day saved due to time I'm not waiting for my hard disk.
ROI for a $300 aftermarket SSD is 75 working days, after that they're effectively earning back ~$1000/year. Considering that our replacement cycle is 3 years, that pays back the purchase cost of the hardware. My boss now buys SSD upgrades for all of our new laptops.
On a personal note, I happily payed $1.00/GB for a hard drive several years ago, and thought it was a pretty good deal. I retired that drive only last month (too small for even my kids' computer these days). Now that SSDs are $1.00/GB it's an easy sell to my wife, and she sees every day the difference in boot times between her desktop and the kids' one (which she used to use until a year ago). I don't think I'll ever run a spinning platter HDD as a boot drive again.
SSDs: a hardware solution to a software problem. (Score:3, Interesting)
SSDs are, in case of a typical desktop system, a hardware solution to a software problem. The software problem lies squarely with braindead legacy APIs that last made sense in the 80s. Those are exposed by seemingly every operating system out there. The issue is as follows: when an application accesses storage, it has no way of telling the operating system what are its plans besides the very next access*. The OS can't plan any hard drive access patterns nor do any sort of large-scale elevator access coalescing because, for the most part, it only knows about the very next access a thread wants to do. Using threading as a workaround to this issue is just silly, you don't need multiple threads, just better async and queuing APIs, and programming languages that can actually deal with them.
Say you know that you want to read the entirety of, say, a dozen configuration files, and also want to read some known byte ranges on other files. It's not simple or even possible, as things currently stand, to tell the OS: here's all that I want to do, wake me up when it's all done. There are asynchronous APIs, but those are not in widespread use because widely deployed C-like programming languages are a very poorly suited to dealing with such problems. As in: the code becomes a royal mess. That's why many GUIs get blocked by every file access and whatnot: it's messy to code an event driven application in a C-like language. Clean, linear-flow code becomes fragmented across functions/methods or case sections. Ugh.
On top of that, all higher-level APIs: those that encapsulate file- and network access, almost universally hide the low level operations and do not allow any sort of asynchronous operation from the caller. Just look at every single damn database library: it's all blocking access! Compression libraries: blocking access! File format libraries (scientific, GIS, office, XML, make your pick) -- same thing. There's no way to use such a library to essentially queue a bunch of requests with the OS, that the OS can then elevator sort on, etc.
Same goes for the runtime linkers/loaders: there's no provision, usually, for any sort of parallelism in queueing the file access requests to the OS. The linker/loader will deal with one file at a time: open it, read some of it, process, rinse and repeat, in spite of knowing a priori a large number of such requests that could all be optimally accessed.
Sure, a realtime database system that needs to have lots of random *read* transactions probably must have an SSD, there's no way around it. A realtime system with mostly random writes can use a log, though, data from the log can be fed back to the database pages after being elevator sorted and coalesced as appropriate, trading off battery-backed RAM for HD performance.
*Let's discount the file access hints as those don't make much of a dent in typical use.
Re:Sequential speeds are irrelevant (Score:5, Interesting)
Re:Hybrid Drives (Score:4, Interesting)