Slashdot Mirror
All Solid State Drives Suffer Performance Drop-off
Lucas123 writes "The recent revelation that Intel's consumer X25-M solid state drive had a firmware bug that drastically affected its performance led Computerworld to question whether all SSDs can suffer performance degradation due to fragmentation issues. It seems vendors are well aware that the specifications they list on drive packaging represent burst speeds when only sequential writes are being recorded, but after use performance drops markedly over time. The drives with better controllers tend to level out, but others appear to be able to suffer performance problems. Still not fully baked are benchmarking standards that are expected out later this year from several industry organizations that will eventually compel manufacturers to list actual performance with regard to sequential and random reads and writes as well as the drive's expected lifespan under typical conditions."
How can that be? They tested every drive in existence?
Just place SSD drives to usenet or torrent servers and use them as /var/log mountpoints... you soon see real tests how well those work when comparing to old fashion harddrives!
Even the article itself says that it isn't much of a big deal, once you get past the headline, of course.
And this seems like the sort of issue that will be resolved in the next generation, anyway.
... these things aren't going to be a big deal in the long run, I mean who wasn't expecting some amount of technological immaturity? We shouldn't forget though that even with it's immaturity it's still much faster then hard disk drives but the SATA interface controller was not designed to handle such high speeds, not to mention much software is not geared, nor optimized for SSD usage.
Still price has come down considerably on many SSD's over the last 6 months, I was thinking about picking up an X-25 M for a mere $350 bucks, would be worth it (to me) just to reduce load times in games like Empire total war IMHO.
This isn't a bug, it is a property of flash memory. That is like calling a car that eventually runs out of gas poorly designed. The only way around it would be a new type of "defrag" where unused blocks were cleared in advance and partially used blocks consolidated.
Think I'll stick with the tried and true IDE/SATA tech.
The Navy Motto "IF it ain't broke Fix It" "A day is wasted if you don't learn something new"
"Drastically effected its performance"
This is patently false. Whats really happening is that SUSTAINED WRITE PERFORMANCE decreases by about 20% on a full drive as compared to a fresh drive. You might say 20% is too much, and I'd probably agree with you, except that ONLY sustained write performance is being affected.
Your read speed will not decrease. Your read latency will not increase. Unless you're using your SSDs as the temp drive for a high definition video operation (And why the hell would you for that? Platter drives are far better suited to that task between sequential write speed and total storage space) then you have nothing to worry about.
This happens on all drives, as the article title correctly states. The solution is a new write command that pre-erases blocks as you use them, so the odds that you have to erase-then-write as you go along are decreased. Win7 knows how to do this.
Nonetheless, it is totally overblown and your SSD will perform better than any platter based drive even when totally full.
http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=4
Anandtech has a very detailed article that explains all about this and some ways to recover the lost speed (sometimes).
-Lod
...you mean to tell me that fragmentation *reduces* the performance of storage???
I purchased a Lenovo X301 with a 120 GB flash drive last September and have been nothing but pleased with the performance of the drive. I boot Vista and also run openSUSE in a vm. The drive speed is high and consistent. The drive in the X301 is supposed to have better controllers than some, and it certainly does better than a USB stick. Any theoretical problems with write speed don't appear to me to affect typical real world use.
One that can relocate MFTs, most used files and swap to the chips on the outer edge of the circuit board, where the throughput is faster.
The fundamental problem with NAND-based solid-state drives is that they use NAND flash memory--the same stuff that you find in USB flash drives, media cards, etc.
The advantages of NAND is that NAND is both ubiquitous and cheap. There are scads of vendors who already make flash-memory products, and all they need to do to make SSDs are to slap together a PCB with some NAND chips, a SATA 3Gb/s interface, a controller (usually incorporating some sort of wear-leveling algorithm) and a bit of cache.
The disadvantages of NAND include limited read/write cycles (typically ~10K for multi-level cell drives) and the fact that writing new data to a block involves copying the whole block to cache, erasing it, modifying it in cache, and rewriting it.
This isn't a problem if you're writing to blank sectors. But if you're writing, say, 4KB of data to a 512KB block that previously contained part of a larger file, you have to copy the whole 512KB block to cache, edit it to include the 4KB of data, erase the block, and rewrite it from cache. Multiply this by a large sequence of random writes, and of course you'll see some slowdown.
SSDs will always have this problem to some degree as long as they use the same NAND flash architecture as any other flash media. For SSDs to really effectively compete with magnetic media they need to start from scratch.
Of course, then we wouldn't have the SSD explosion we see today, which is made possible by the low cost and high availability of NAND flash chips.
Yeah, the latency on high-end sequential writes will go from 0.08 ms to 0.10 ms.
Ummm, that's still an order of magnitude faster than any physical disk.
Wanna bet SSDs still work wonders as purposed devices for file systems like GPFS, QFS, ZFS, and XFS (the real version, not the crippleware that SGI GPL'd...) even after they "slow down from use"?
At least as long as you stick to the proven drives like Intel and Samsung (and probably a few others by now) and don't buy one of the utter crap drives out there now.
This is old news, and both the Intel drives and the OCZ Vertex have updated firmwares/controllers that remedy (but do not completely solve) the issue.
When we get support for TRIM, it will be even less of an issue, even on cheapo drives with crappy controllers/firmware.
The issue won't be completely solved ever, because of how SSD arranges flash memory and how flash memory can't really be overwritten in a single pass.
See anandtech's write up if you want details.
http://www.anandtech.com/printarticle.aspx?i=3531
The real solution is to expose the flash block layout through the I/O bus and let the operating system and filesystem manage this itself. The flash-optimized filesystem would do more to aggregate writes into full erase-block size pieces and flush them to the flash device in one efficient pass.
Let the OS understand data block->erase block packing and just leave the device to manage wear-leveling of erase blocks by logically remapping them onto the real physical flash erase blocks.
Power management can turn off sections of the flash memory. This is good, of course, to reduce battery consumption in laptops and netbooks. But the process of turning a section's power off and then turning another section's power on can slow down the access. With very random access, expect that to simply happen a lot. So random hopping around the storage, while not as slow as a mechanical hard drive, will be slower than sequential.
Add wear leveling into the picture and you have a layer of memory translation. The purpose is to select different blocks out of a pool each time an erase needs to be done. So if you write over the same page of storage a million times, it is actually erasing a number of different blocks. In real world writing, which has its own random access, the end result over time is that this translation layer has the data scattered all over the available space.
Now even a sequential access to the data is really accessing the data in a random order based on what the wear leveling translation layer state is. This increases the number of times the access transitions from power controlled section to another. If the design is one where few or even one section can be powered on at the same time, this slows things down even for a sequential access. If the design allows many or even all sections to power on at the same time, then it shouldn't slow down (just for sequential reading), but would increase the power drawn and shorten battery charge/life if on battery power.
What would be useful ... if you don't mine occasionally losing all your data ... would be some kind of reset operation that can be done to the whole SSD device to discard and re-initialize the wear leveling translation (but not discard the bad blocks data). You could sequentially write over the whole device, which will help some, but won't be a complete re-initialization. The OS needs to be writing to the device in units of at least the erase block size in order to do this right. Multiple whole writes might do better than just one, but this is accumulating more wear on most (or if enough passes is done, perhaps just two ... all) blocks.
now we need to go OSS in diesel cars
So according to what you're saying, and what the Anandtech article said, the headline is just plain Wrong!
http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=1
The slowdown is only particular to NAND Flash. Dynamic RAM based solid state drives don't suffer from this phenomenon. (Gigabyte i-Ram and ACARD ANS-9010) However, they are definitely also Solid State Drives.
This is going to be a much bigger problem on FAT32 and NTFS, than modern Linux filesystems because FAT32 and NTFS fragment after very little use.
If you're worried, increase your block size. That shouldn't be a problem if you're writing media to the disk (as opposed to a billion tiny files, in which case large blocks would waste extra disk... but still be able to withstand fragmentation...)
If you read the article, Intel is reported to have fixed the problem with their X25-M SSD with a firmware update, and no data are provided to indicate that the problem remains. If Lucas123 is going to claim all drives suffer from the problem, then s/he needs to provide data to support it. Otherwise, it's just unscientific conjecture. Not that I don't believe it's still an issue, but no data are actually provided in this article!
http://www.computerworld.com/action/article.do?command=printArticleBasic&taxonomyName=Storage&articleId=9132668&taxonomyId=19
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
This isn't a problem if you're writing to blank sectors. But if you're writing, say, 4KB of data to a 512KB block that previously contained part of a larger file, you have to copy the whole 512KB block to cache, edit it to include the 4KB of data, erase the block, and rewrite it from cache. Multiply this by a large sequence of random writes, and of course you'll see some slowdown.
Unless you're using a COW / log-based file system, in which case you never write back to the same "LBA" of the device.
Once the SATA TRIM command is more widely supported, the OS will then tell the device to clear the no-longer-being-used LBA (assuming it doesn't need to be kept around for snapshots like in ZFS).
I've used it as a desktop drive for four months so far, and, using hdparm -T as a benchmark (I know, I know, but it's on a desktop!) it has the same throughput as it ever did. I download torrents to it.
It would copy completed torrents to a platter-drive at 60MB/sec when new and will still do 60MB/sec now.
I don't see a problem. Opera/Firefox open in less that one second (by wristwatch!) instead of ten on a platter-drive (Pentium-M, 1.6 GHz). The whole computer seems more responsive -- even modern in terms of speed.
Thumbs up on SSDs! My Patriot drive was on sale at Fry's for about $70 US (32GB). Best upgrade I ever made; I boot from it (less than 20 seconds on Ubuntu 9.04) but use a platter drive for /home and swap.
Looks like it. they're all borked. Every single one of them. I said so in the title, and I only bother reading the title in Slashdot stories these days.
http://4onlineshop.stores.yahoo.net/an5insax1ram.html
The ANS9010 and 9010B suffer no such issues since they are ram-based. They also have a CF backup slot in addition to a backup battery. Very slick and a better solution for a boot drive than a typical SSD if you absolutely must have maximum speed. Pricing with RAM is comparable to an enterprise-level SSD, just roughly 1/2 to 1/4 the capacity is all.
On page 8: Putting Theory to Practice: Understanding the SSD Performance Degradation Problem
I don't need to test my programs.. I have an error correcting modem.
What's the big fat hairy deal? Correct me if I'm wrong, but with SSDs access times out of the ms and in the ns range SATA is the bottleneck for those aswell. As it has been with throughput ever since we've had upwards of 5K RPM disks and upwards of 8MB cache on the controllers. Which was around 2002 IIRC.
In fact, it's actually the strangest thing to connect a SSD via SATA in the first place. A waste of power, space, time and complexity. Throughput wise anyway. An entirely different diskbus is long overdue. USB 3 could maybe be a candidate, no? One piece of outdated legacy less - allways a good thing imho. I personally thought of skipping SATA entirely and using internal USB 2 instead, back in the day when SATA was the hottest new thing.
We suffer more in our imagination than in reality. - Seneca
Firewire.
this is my sig
I'm running an Intel x25m as my boot drive, I've used the system with and without the SSD, you'll pry the SSD from my cold dead hands. The responsiveness when using the SSD is astonishing, apps just spring open as fast as you can release the mouse button.
wrote a thorough review of SSDs, including the X25, complete with a full technical explanation of exactly what causes the performance degradation.
About 2 months ago.
I agree that it is not news (the topic, including performance reviews, was thoroughly covered by Tom's Hardware about 2 months ago), but the OCZ Vertex did not in fact "update" the controller. The new top-of-the-line Intel SSD does indeed have a new controller, that helps to minimize (but not eliminate) the issue. OCZ, on the other hand, just threw in another of the old controllers, and divided the memory between them to increase average throughput. The problem is still there, but it is somewhat less noticeable because the throughput is better on average.
However...
As long as they can get the read, write, random read, random write performance to be substantially better than a hard disk - across the board I don't care too much. .ico files on it (754 bytes?) in a zip file.
Example: many many years ago, on my 286, I extracted a floppy disk with 1,800
That took about an hour to do.
I then learned about 'smartdrv.sys' (or was it EXE?)
The time to do it went from an hour to about 30 to 60 seconds.
The way the FAT16 worked on my machine with a 20mb drive and a 286 CPU it was writing back and forth constantly for that many files, it was very in-efficient, each subsequent .ico file being extracted from the zip made it slower.
Now if we have some kind of alternative which alleviates this problem in Windows (and can still keep write corruption down, in the event of a power failure) I'd be curious to see it implimented.
Sooner or later SSD's will be better than magnetic hard disks, across the board (possibly inclduing space) right now there's some issues but I'm thinking, after Anands huge article a month or so ago, the manufacturers know that the consumers are switched on to this.
You'll see an OCZ Vertex 2.0 drive sooner or later, across the board faster than the 1.0, possibly cheaper and possibly bigger.
I would guess, within 18 months 'regular' non geeked out enthusiasts will be snapping up SSD's and within 48 months from now, you'll see SSD's shipped commonly in laptops and desktops purchased from IBM, Dell, HP at regular prices for regular office worker workstations (600$ US jobbies)
I for one, can't wait.
In case someone is wondering: no technical parts of this article say anything interesting. USB is certainly not a good replacement. USB-2 is way too slow and has terrible latency. USB-3 will be better, but it won't go faster than current SATA-2. And no, the write speed of SSD's won't surpass SATA-2 for any reasonably numbers of chips for hard drive replacement.
The only real competitor for SATA currently is the PCI-e bus. If you would create an SSD with seriously low latency and many parallel chips, hooking it up directly to a serial PCI slot with x2 or more lanes would make a difference. It would help if the BIOS and OS still see it as an IDE drive through.
And what's new about that? when any disk get fragmented the performance will degrade also in the future.. People who didn't think of that are waaaaaaaaay to naive.. The only difference is that defragging should be much faster as with a regular disk..
but has anyone come up with a system that has variable sized blocks. It might be a useful trick to make it easier to pack the disk, and unpack it so to speak.
"I have some experience with SSD's on development machines and database servers. I speak from experience when I say they are much less reliable than the old spinning hard-drives when used in those environments. In fact, I have never seen a single one last more than a year." - by Anonymous Coward on Friday May 08, @08:05PM (#27883837)
That's untrue in my experience, & that has been using a TRUE SSD (not based on FLASH ram w/ its slower write cycles, of which I figure @ least, only write-back caching could offset, as to slower write performance on FLASH based ssd media), AND FOR NEARLY 7 YEARS NOW TROUBLE FREE, no less, called a CENATEK "RocketDrive" (PCI 2.2 slot bus, & PC-133 SDRAM).
I use it for these purposes here (and, this is since late 2002 no less to present day 2009, no problems @ all whatsoever):
----
PARTITION #1, 1gb
1.) pagefile.sys placement
PARTITION #2, 1gb
A.) Webbrowser (Opera, FireFox, & IE) caching location
B.) %temp% & %tmp% ops placement (environment alteration)
C.) SandBoxie placement (a webbrowser sandboxing tool, goes VERY slow on std. HDD's, & much fsater on this SSD, by far)
D.) Print Spooler location
E.) Windows' EventLogs
F.) DrWatson Logging
G.) Windows' Firewall logs
H.) Windows Management WMI logging
I.) HOSTS file placement
J.) %comspec$ placement (cmd.exe location, environment alteration)
----
All for 2 reasons:
1.) Greater seek/access speeds
&
2.) NOT "cluttering" my main disk w/ them (which can aid fragmentation also) + NOT burdening my MAIN C: drive (OS & Programs MOSTLY here only) w/ dealing w/ those files & tasks associated w/ them...
(IT WORKS, & just on "common-sense" principals)
APK
P.S.=> This, however, is because I use a type of SSD that while smaller, capacity-wise than today's FLASH-RAM based ssd's, doesn't suffer from lower write performance, nor does it require wear-levelling to offset performance degradations either. - AND, there is a BETTER type that is affordable too, called a GIGABYTE IRAM (SATA bus, DDR-RAM (both faster than the tech employed by the model I use, listed above)... apk
Once again I'm shocked by how terrible Slashdot is for anything hardware related. Just as has been said every time anyone has mentioned these pathetic articles from magazines like Computerworld (!), THIS ISN'T NEWS - ANANDTECH EXPLAINED IT VERY CLEARLY MONTHS AGO.
http://www.anandtech.com/storage/showdoc.aspx?i=3531
Even without reading an article, I'm surprised this isn't intuitively obvious to most Slashdot users. I'm also surprised that the majority of hardware articles posted here come from jokes like Computerworld. There needs to be a Shouldhavecheckedanandtech tag for stories.
Windows 7 actually eliminates this degradation for all SSDs through inclusion of the TRIM command, but the necessary cost is shorter device lifetime, which is why the TRIM command won't run automatically. Likely, other operating systems will include it within a couple years.
"I zero-index my hamsters" - Willtor (147206)