AnandTech Gives the Skinny On Recent SSD Offerings 96
omnilynx writes "With capacity on the rise and prices falling, solid state drives are finally starting to compete with traditional hard drives. However, there are still several issues to take into account when moving to an SSD, not to mention choosing between a widening array of offerings. Anand Lal Shimpi of AnandTech does a better job than anyone could expect detailing those issues (especially those related to performance) and reviewing the new offerings in the SSD arena. Intel's X25 series comes out on top for sheer speed, but OCZ makes a surprise turnaround with its Vertex drive giving perhaps the best value."
Finally... (Score:1)
Re: (Score:2)
totally off topic, but I met Anand recently in Raleigh (Ive been a reader of the site for years, and a regular in the forums as well) and hes a very smart guy, quite nice, as well as interesting. The articles they do are usually pretty lengthy, and in-depth enough that I rarely bother to read the whole thing.
Turns out that as popular as his forums are, a few large companies actually have people on payroll just to read the forums and collect feedback (lots of tech enthusiasts there, especially concerning vid
SSDs get slower the more you use them (Score:2)
I didn't know that. And it sucks.
Re: (Score:3, Informative)
I didn't know that. And it sucks.
No. Not use, but slower the more you write to it. You can read all the time and it doesn't speeds.
The article goes into detail why writing does cause problems. The author does conclude even at the slowest possible speed the Intel model (he said he did a simulation where by writing to all the blocks at least once) that its still beats HDD.
The other versions he tested shows wasn't at great.
Apparently it depends on the controller version which affects the speed. Intel put a goo
Re:SSDs get slower the more you use them (Score:5, Informative)
No. Not use, but slower the more you write to it. You can read all the time and it doesn't speeds.
Not quite. Once it runs out of completely free blocks, the drives 'hit a wall', and from that point on they are significantly slower to write to.
But it doesn't continue getting slower and slower and slower and slower over time. Just that, at some point, it suddenly becomes x% slower to write to and stays that way.
The author does conclude even at the slowest possible speed the Intel model (he said he did a simulation where by writing to all the blocks at least once) that its still beats HDD.
The intel model is the fastest by far. The Samsung drives are also good. And the OCZ Vector was also good. (Not as good as the intel one, but still 48% faster than the WD veliciraptors, which is seriously still excellent.)
The important point however, is that the units that 'still beats HDD' doesn't mean "a little bit faster". They mean continue to royally spank an HDDs ass.
However, the other models, by comparison, are basically unusable.
Apparently it depends on the controller version which affects the speed. Intel put a good one in and the other brands no so good.
Its FAR more complicated than that by far. And the article is 30+ pages long for a reason. (30+ real pages, not bullshit 'half-paragraph per page' pages.
He said its still noticeable though sometimes.
In the sense that yes, once your drive 'hits the wall' the slow down can be noticeable relative to when it was new... but its still twice as fast to 5x as fast as the fastest alternatives.
There is also stuff the OS can do to mitigate the problem, once we have SSD aware OSes.
Essentially, the reason it slows down, is that once your drive has used all the blocks, it has to erase a block before it can use it again, and this can require it to read multiple pages in, erase the block, and write it back out again, which can take up to half a second.
The better controllers, including extra blocks that aren't reported to the OS, and adding OS awareness to the issue can essentially let the drive stay ahead of the random write requests, and erase blocks before they are needed, to ensure their is always a pool of completely erased and ready to go blocks available, and therefore keep the drive much closer to its 'like new speed' indefinitely.
Re:SSDs get slower the more you use them (Score:4, Informative)
Mod parent up. I'm not arguing with him, but merely emphasizing a key point.
... and adding OS awareness to the issue can essentially let the drive stay ahead of the random write requests, and erase blocks before they are needed, to ensure their is always a pool of completely erased and ready to go blocks available, and therefore keep the drive much closer to its 'like new speed' indefinitely.
Actually, this is the part about the new sata Trim command. And ironically a part where Anand swings and misses completely, or it's dumbed down to a level where it is completely misleading.
It's not so much about making the OS SSD aware in the sense that the OS now knows about the inner workings of the SSD, but making the SSD aware of what space is actually used for data, and what has been discarded. Knowing what data blocks has been discarded means you can consolidate discarded blocks, by moving valid data to other pages, and then erase the page full of discarded blocks, so it is ready for writing new data.
So not only do you get write performance that doesn't degrade with time, but you can also store slightly more, because you don't have to reserve as much space.
Re: (Score:2)
It may not be a big deal. All you would have to do is create your encrypted partition that's slightly smaller than the entire disk (say, 1-2GB less). That way, you'll always have empty blocks available for writing files to, and due to the way the drive works, these empty blocks will essentially move around randomly on the drive as you make writes to it. Of course, this is assuming that the drive doesn't automatically do that for you, as the article mentions that some drives keep a few % worth of blocks a
Re: (Score:3, Insightful)
Adding cache RAM would mitigate a lot of the problems too. It's a shame only high end RAID cards have it, because it could really help out both HDDs and SSDs.
Basically you have a relatively small RAM cache for the drive. It could be in the drive itself or on the motherboard, depending on how you want to do it. When any data is written to the drive, it goes into the cache RAM and gets written out as quickly as the drive can manage. From the OS's point of view the write completes as soon as the data is in cac
Re: (Score:2)
1. Hard Drives do this already. [wikipedia.org]
2. Some of the SSDs in question do this already. [anandtech.com] [TFA]
3. Most filesystems do equivalent things already by delaying and aggregating writes.
From the OS's point of view the write completes as soon as the data is in cache RAM, which is almost instantly.
As stated, this is a Bad Thing. Most of the time, it is acceptable, but the filesystem (which is what you meant) does occasionally need to be able to force data to be written to disk immediately.
What do they say on Everything2? "Your revolutionary ideas on the future of storage have already occurred to others." Depending on your specific nee
Re: (Score:2)
You have failed to understand what I was suggesting.
Using cache RAM on the drive or the controller is different from having more RAM for use as cache by the filesystem or the OS. You correctly state that sometimes the filesystem needs to know that data has really been committed to disk, and then go on to say that having cache RAM is thus a bad idea. Apparently you didn't read the bit I wrote about backup batteries/capacitors.
The whole point I was trying to make is that because SSDs are low power, it isn't a
Re: (Score:2)
I read your post in its entirety. It is uninformed on several levels, and a completely inappropriate solution to any given problem.
Do note that this device already exists in a couple different forms, and is selling extremely poorly.
This device would be horribly expensive. In essence, you are paying for the same amount of storage twice, plus a bunch of specialized electronics. The base cost for the device would be about $250. Flash memory costs dollars per gigabyte, DRAM costs tens of dollars per gigabyte. A
Re: (Score:2)
You clearly have no idea what you are talking about, and still have not managed to grasp my original point.. Nicely done.
Your costing is way, way off. You also seem to imply that you would need as much RAM as you have solid state storage, but that too simply is not the case. The RAM would be for cache use only. so does not need to be bigger than say 64MB if you really want to save some money, Also, you seem to have no idea about battery/capacitor cost, or what type/size would be required.
Most of the faster
Another thing you might want to do (Score:3, Informative)
In Windows NT/2000/XP, Linux, FreeBSD and a few other operating systems, the O/S by default writes to the drive on every file/directory access to update the "Last Accessed Time".
This means the O/S will write stuff every time it opens a directory or file, even if it's just for reading!
This is bad for drive performance whether "conventional HDD" or SSD. And extremely bad for the crappier SSDs that don't do writes well.
You can turn that "ins
Re: (Score:2)
In Windows NT/2000/XP, Linux, FreeBSD and a few other operating systems, the O/S by default writes to the drive on every file/directory access to update the "Last Accessed Time".
In most file systems, if not all, I would imagine that these time stamps are stored in the directory "file" itself, not within the actual files in the directory. So its not like every file is being touched every time its accessed, just the folders they are in.
Granted, turning off last access times would reduce writes to the director
Re: (Score:2)
That will cause slowdowns for SSDs with high write latencies.
You can check the percentage for your usage, start perfmon.msc and add the relevant counters e.g. disk writes/sec and disk transfers/sec. Then do your real world stuff.
Re: (Score:2)
You can check the percentage for your usage, start perfmon.msc and add the relevant counters e.g. disk writes/sec and disk transfers/sec. Then do your real world stuff.
Trouble is I intuitively think the percentage is pretty low, so even running the PC for a couple weeks with it on and them a couple more with it off I don't think I'd be able to positively conclude the difference could be attributed to timestamp writes from the results. I'm not even sure if existing benchmarking software suite could be used t
Re: (Score:2)
Ingo Molinar says [kerneltrap.org]: "I cannot over-emphasize how much of a deal it is in practice. Atime updates are by far the biggest IO performance deficiency that Linux has today. Getting rid of atime updates would give us more everyday Linux performance than all the pagecache speedups of the past 10 years, _combined_."
Re: (Score:1)
It's not as if nobody noticed - the rest of us were working around that with noatime and similar stuff.
Sometimes I wonder if there are people going about looking for ridiculously pathetic stuff like that, and working to get them fixed.
Another example - for years the hardware people did not create an easy way for the software people to do "gettimeofday" on desktops. The hardware people were telling the software people - no don't u
Re: (Score:3, Informative)
Not really, no. (Score:5, Informative)
Reformatting isn't sufficient to get back to new performance, you have to issue an ATA SECURE ERASE command.
And you can't run a filesystem built specifically for flash on these drives, with Linux or otherwise, because they don't present a flash interface. They present an SATA interface.
In any case, the take-home message is probably to consider the drive's "used" performance as its real performance. If the drive is not a crummy one (watch out for those), it's still _much_ faster than an HDD, and very worthwhile depending on your application.
Re: (Score:1)
And you can't run a filesystem built specifically for flash on these drives, with Linux or otherwise, because they don't present a flash interface. They present an SATA interface.
However you CAN run any Log-structured file system [wikipedia.org] that isn't tied to MTD devices. However that only delays the write performance hit until you've wrapped the drive, you'd still need some way to inform the drive that blocks X to Y are unused and can be erased.
Re: (Score:2)
Interesting. The ATA TRIM command, which hopefully drive firmware will start supporting, could work for that. But you'd also need some way to turn off the fancy wear-leveling and other algorithms on the drive itself, and also you'd want some way to unlock the extra storage which the drives physically have but don't present over SATA.
Re: (Score:2)
In the article he mentions the new trim command, that will be similar to defrag I guess. But a lot quicker, and can be run internally on the drive.
And you can write a file system for these new drives, in the article he mentions how to do it as well.
Re: (Score:2)
And you can't run a filesystem built specifically for flash on these drives, with Linux or otherwise, because they don't present a flash interface. They present an SATA interface.
The OS can simply query the rotational speed. Anything that responds with 0 is generally a flash drive. There's also no reason that an OS shouldn't allow you to put whatever filesystem you want on a drive when you format it if you have a flash-optimized fs already present in your OS. Some of the blame lies with OS's as well as the drives.
Re: (Score:2)
Re: (Score:2)
I don't see that as a problem. In fact I see that as a good thing. Otherwise think of all the buggy custom drivers you would be plagued with.
I'd rather the SSD manufacturers improve the technology so that the O/S doesn't have to know about such stuff.
What's important to have is stuff like "make sure data is flushed to nonvolatile storage", features that will remain important for decades to come.
Re: (Score:2)
Is there really any reason you can't simply have the OS automatically "zero" the space used by any file that is deleted? This kind of thing can already done as a security measure as it is for spinning disks. The only problem with that I could see is that eventually if the drive gets really fragmented, you'll eventually reach a point where every block will have some pages containing data so you'll still have to do the erase and rewrite business to write a file.
Re: (Score:1)
In a way, it is a physical problem. With hard drives, seek times are slow compared to read and write speeds, and reading and writing happen at the same speed. With flash, seek times are negligible, and read speeds are much faster than writes. It's that inequality of read and write speeds that messes up so many of the assumptions our current software makes, and leads to behavior that users find disturbing.
Re: (Score:2)
Re: (Score:2)
Actually in the article he specifically points out that it is a physical problem that doesn't depend on any external factors.
After all of the blocks have been used the first time a new physical delay is introduced: the need to erase old blocks.
Re: (Score:2)
great article (Score:2, Insightful)
i read this article yesterday and thought it was very interesting. I didn't know much about SSD's besides the common "better performance but not worth the money" opinion. Nor did i know about the 1st gen problems that most of them have. Good stuff, anyone interested in getting a SSD soon should definitely read this.
Re: (Score:2)
Mod parent up. This is REALLY the best article I've EVER read about SSD performance. If you are interested in buying an SSD do yourself a favor and read it, and understand it.
Re: (Score:2)
Mod parent up. This is REALLY the best article I've EVER read about SSD performance. If you are interested in buying an SSD do yourself a favor and read it, and understand it.
Anand consistently delivers top notch articles. They've had the same, unobtrusive, useful interface for the last, oh, 8 years now? They haven't pumped the site full of advertisements either like some other *cough tomshardware cough* websites.
For other good reads from Anandtech check out the DX11 writeup [anandtech.com] or their Intel SSD [anandtech.com] article.
Re: (Score:2)
This is almost the perfect review. Anand gives us his methodology, reveals his contact with manufacturers in context, and explains fully what the tests mean and why they were designed
2009 is the year of the SSD (Score:3, Informative)
I saw this article earlier today off a comment from Engadget and read the whole thing (no printer friendly version).
Out of curiosity, I searched Amazon.com [amazon.com] for current offers of that Intel X25-M and in both offerings (80gb and 160gb) the reviews are that this thing is the greatest thing next to sliced bread.
The only complaints are the price but people are claiming its worth the price.
I did come across a detractor that shows you can't use XP/Vista on bootcamp [apple.com] with the drive because of partition issues with OS X.
Supposedly Windows 7 will have true blue SSD support so I'll wager by the time it comes out, SSD will be standard in all machines.
Re: (Score:3, Funny)
Did Sony just invent yet another format while nobody was looking?
Re: (Score:1)
IBM, actually.
Re: (Score:2)
Supposedly Windows 7 will have true blue SSD support so I'll wager by the time it comes out, SSD will be standard in all machines.
Sure but by then we should also have solved world hunger, cured cancer and conquered Mars!
(I kid, I kid)
Bad controller (Score:2, Insightful)
Re: (Score:2)
How TF are you getting RAID-10 [acnc.com], which requires 4 drives, out of two drives? I'm guessing you mean RAID-0 [acnc.com] built around two drives. Maybe you have something funky like RAID-10 built from four partitions on two drives, but that makes your redundancy moot.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
WOW (Score:5, Informative)
Re: (Score:2)
Will TRIM work thru SATA Raid controllers? (Score:2)
Re: (Score:2)
whether the TRIM command work through a RAID controller and actually reach the SSD?
Probably not. RAID controllers will need new firmware.
Re: (Score:3, Informative)
it is important to know whether the TRIM command work through a RAID controller and actually reach the SSD
Not really. Stop using hardware RAID. It's dangerous, expensive, and not necessary.
The best thing you can do is use ZFS. It even optimizes for SSDs.
TRIM vs. TI Garbage Collection (Score:1)
Re: (Score:3, Informative)
It isn't. The whole point of TRIM is to erase a block before you're waiting to write something to it, ie. before your disk is full and you need to reuse the space. The garbage collection on a TI calculator is really defragmentation, to eliminate gaps between files. This is necessary because the calculators have the flash attached to the address bus, rather than behind a hard drive controller, and there's no MMU to give programmers a linear address space if there flash apps were to be discontiguous in memory
Hybrid? (Score:2)
Perhaps a hybrid model will arise, which keeps usage statistics for files, and allows for mostly-read and marked-read-only files to go migrate to SSD.
I would want most of my high-traffic files (development work, application caches) to be fast-write at all times and relatively immune to data congestion. But praps silent overhead will just bump up to 50% as prices go down, with a new analogue to defreg, the "flatten" or such.
Flash-oriented file systems. (Score:3, Interesting)
The real solution is going to be when the OS (which knows what that data really means, which is file and which is metadata and which is cache and backing store) and not the flash controller does all the wear leveling and block erasing, bypassing the flash controller as much as possible. Which is going to require new APIs and interfaces.
Re: (Score:3, Interesting)
Re: (Score:2)
In fact, Linux already has a few flash file systems.
Re: (Score:2)
I can certainly understand the desire to let the OS "not handle" stuff, because there are plenty of OS's that do a bad job... "handling" stuff, to be sure.
But that's its job. It multiplexes your CPU to handle hundreds of threads at the same time, making each one think it has the entire CPU to itself. That's a pretty big job, and we trust the OS to handle it. Sure, there is a need for a good interface, a good point for what has to be abstracted and handled by the disk, what has to be handled by the OS - b
Re: (Score:3, Informative)
MacBook (Score:2)
Amazing Article (Score:4, Insightful)
Re:Amazing Article (Score:5, Informative)
"some geek"?
Anand has been around, reviewing hardware, for close to 10 years now. He is, rightfully so, considered an expert in hardware usage, performance tuning and over systems construction.
There are others out there with similar cachet.
He is far, FAR from just being "some geek".
Re:Amazing Article (Score:4, Insightful)
Does he have an engineering degree? Could he have made the change to the firmware himself? Does anyone but other geeks know who he is?
I'm not trying to badmouth him, it's amazing that he does what he does, but it isn't immediately obvious why he carries so much respect.
Re:Amazing Article (Score:5, Informative)
If you took 5 sec. to search his credentials you'll find he graduated from N. Carolina State with a CE degree.
His site has been in existence for quite some time and I find his articles are among the better ones on the net, but you may want to read others and compare. The reason why I like his articles over others is the depth of his articles. He describes the underlying architecture and provides thoughts on why he thinks a company chose a path with followups that either reinforce or refute a theories.
Re: (Score:1)
I've always liked Anand's articles primarily because he's not afraid to be frank and say something that's bad is bad. He doesn't sugar coat. Sometimes, when a product launches, he reviews it, and he says it doesn't live up to the hype, or X thing is missing/wrong/etc, I get bummed, but he does quite well at putting it all into perspective.
At the same time, I "feel" this giddy-nerd-joy when he writes about something that is ground-breaking or game-changing (RV770, Nehalem, etc). Take a look at this article,
Re: (Score:2)
I'm not trying to badmouth him, it's amazing that he does what he does, but it isn't immediately obvious why he carries so much respect.
The site at least (anandtech) gets respect because from them, articles of this quality level are not perceived as a fluke.
Merely as an example, if this had come from Tom's Hardware, I would have been floored.
Re: (Score:2)
>Does anyone but other geeks know who he is?
Does it matter? You seem to be surprised by how the market works. Products get reputations. In technology this is driven largely by benchmarks. In every industry there are guys like him who are unknown outside of the industry. It doesnt matter if he's unknown to 99.9999999999999 of the people out there.
Also the web is something of a meritocracy. He's popular because x amount of people think he's good at what he does. Hes not some guy who just registered a blogs
Re: (Score:2)
Anand is alright ..I've been reading his site for years. For info on consumer-level tech, he seems to know his stuff, although he seems to slant toward Intel a bit too much.
GP is right, though. He is basically just a geek that like to mess around with new HW that also gets to go to all of the consumer electronics shows and things. He just made a business out of it.
Really Excellent Article == Printable Page Link? (Score:2)
That was a really, really, good article that Anandtech put tons of work into. So in response Slashdot hammers them with a zillion people jumping directly to the printable page link? No ad impressions for them, and more bandwidth hit from those that don't read the whole thing. That wasn't nice.
I'm just as likely to hit the printable link as the next guy when a site has a terrible ads, or content/ad ratio, but Anandtech didn't deserve this.
Anand rocks (Score:3, Interesting)
Anyone know anything about heat output of SSD? (Score:2)
I'd be interested in using an SSD as a replacement drive in a laptop but it's passively cooled so I'd need to know it ran cooler than a traditional HD.
Re: (Score:1)
Re: (Score:1)
I was mildly suprised by the results.
Re: (Score:2)
this is how the web works after all [benchmarkreviews.com]
Manufactures doing no real world testing (Score:1)
From reading the artical it appears that none of the SSD manufactures did any real world testing and they only designed their products to maximise sequental read/write performance. Not one ever tried popping it into a real machine to see how it performed.
Re: (Score:2)
FS Blocksize Synchronization (Score:2)
The article goes into detail about the trim command, etc. I thought this whole issue could be avoided by just setting the beginning block to align with the SSD and then setting the FS block size to the same as the erase block on the SSD. This way, every time it gets a request to write a block it always writes the whole thing and doesn't have to worry about reading it or doing any copying.
Re: (Score:2)
Erase blocks are probably going to get larger. Try a typical Unix file system without tail packing on a 1MB block drive...
Lets not get carried away ... (Score:2)
I took the guy just a little less seriously after reading this pie-in-the-sky claim [phrases.org.uk] ;-)