Slashdot Mirror
Performance Showdown - SSDs vs. HDDs
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."
Unfortunately there's no comparisons of battery life and speed tests with fragmented files.
mod me funny
Dunno about the author of this article, but got an "SSD" (hello buzzword) to get rid of the noise, the heat, and the annoying spin-up delay. A compactflash card doesn't cost eleventy billion dollars either.
c++;
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?
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!
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
If your filesystem is designed to distribute the writes properly, the failure time is comparable to the MBF of hard drives.
Though personally, I think the way to go on servers is to use 64GB of RAM and put most of it as a RAM disk. Depending on your application, you can either have a shell script copy the data back to a hard drive for persistent data, or use that kernel driver to mirror the data to a hard drive. Software RAID 1 would work, too.
Not a typewriter
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.
In addition to power usage, some measure of how warm they get under load would be useful too.
Please stand clear of the doors, por favor mantenganse alejado de las puertas
I just ordered a new laptop, and it has an ExpressCard slot into which I could drop 4 or 8 GB of solid-state disk at a reasonable price. That could serve as a giant cache, one that unlike RAM could be safely used as a write cache.
It seems like there would be a clever way to treat the SSD plus the regular hard drive as one unit so that the hard drive could be spun down for hours of normal working situations, giving a giant extension of battery life.
Anybody heard of a virtual block device or special filesystem that would take advantage of this in Linux?
Wrong. Writing to flash requires erasing a block. The erase block size of a typical device is 128K. If I only write 8K, what is this translation layer going to do? Sit and wait until more writes come through? What happens when I shut the system off?