Intel replies to solid-state drive 'slowness' critique
After a technology review site claimed Intel solid-state drives slow considerably after extended use, Intel said it has not been able to duplicate the results.
SSDs have been gaining in popularity because independent testing done to date has typically shown that SSDs--especially the newest generation of drives--outpeform hard disk drives.
A review, however, entitled "Long-term performance analysis of Intel Mainstream SSDs" on technology Web site PC Perspectives claimed, among other things, that the Intel X25-M solid-state drive may degrade in performance as a result of "internal fragmentation" and that "a 'used' X25-M will always perform worse than a 'new' one" and, in some cases, drives "would drop to significantly below manufacturer specs."
The reviewers claimed that they made an effort to reproduce real-world scenarios. "Dozens of different scenarios were played out on our drives. XP / Vista installs, repeated application / game installs, batch copying of files...were all liberally applied to the X25-M." The review concluded that "all three of our SSDs suffered a drop in performance regardless of the type of workload applied to them."
In response, Intel made a statement on Thursday. "Our labs currently have not been able to duplicate these results," Intel said. "In our estimation, the synthetic workloads they use to stress the drive are not reflective of real world use. Similarly, the benchmarks they used to evaluate performance do not represent what a PC user experiences."
Intel continued. "In general, when a PC's drive (SSD or HDD) is full, there will be some reduction in system performance, however the performance reduction reported by PC Perspective is higher than we generally expect, which is why we are looking into the methodology."
Brooke Crothers has been an editor at large at CNET News, an analyst at IDC Japan, and an editor at The Asian Wall Street Journal Weekly, among other endeavors, including co-manager of an after-school math-and-reading center. He writes for the CNET Blog Network and is not a current employee of CNET. Disclosure. 
This fragmentation is entirely within the drive. The OS can't correct this.
That said, we have yet to see more proof of the problem. After all, by claiming their engineers can't reproduce the problem (some time after the article) Intel is either saying that their lab-coat wearing folks are ditsy incompetents or there really is a case for examining the methodology of the test - even if it proves to be that the problem does arise in real-world use, at least the investigation will better define which scenarios.
It was even mentioned that doing benchmarking would tune the drive to that mix of I/O and that it would take a while for the drive to re-tune itself to something more like your average workload.
I think the real 'problem' here is end user stupidity, too-short of an attention span and not doing enough research.
First, fragmentation does not apply to solid state drives. Please remember that. Fragmentation is a problem for rotating media because you have to move the heads to collect the data from different tracks as the block move. There are no physical heads to move on an SSD, so no issue with fragmentation.
There is actually a second issue on rotating media, block latency within a track, that also does not apply to an SSD. Again, not rotating platter, so no latency on a skipped block.
Second, no matter how carefully you try to 'defragment' an SSD, the logical blocks will never be physically coherent over time. Never. The reason being is that you cannot 'overwrite' a NAND (or NOR) block. You must erase it first. The way you manage SSD internally is to map physical blocks to logical blocks, and keep a spare list of erased physical blocks available at all times. When data changes within a single block, you read that block out, mark the current physical block for erasure, map in an empty physical block from the free list to the logical block, then write that new data back.
The dirty blocks are erased and added to the non-allocated blocks as the erase completes. By tracking the erase count for each block in its metadata area, you can perform wear leveling by sorting the available block tree in increasing erase count order. Also, most intelligent controllers scan through the drive and reallocate static data to blocks with high erase counts. This slows down the count growth on those blocks as static data has a tendency to remain static over time. It also places lightly used blocks into the free block tree.
I learned through my experience writing NAND block drivers that your free block/erase scheduler degrades when your allocation exceeds about 80% of the available space. It doesn't lock, but it does slow down. For that reason, I always wondered if, for example, a 80GB SSD really has 100GB of NAND internally to cover for erase/free block management.
Also, NAND (and NOR) erase times extend over time. I am not certain of the mechanics involved, I don't now solid state physics that well, but the first time you erase a block takes less time than the 1000th time your erase the same block, takes less time than the 10,000th time, etc.. Eventually, you attempt to erase a block and it will time out, and the block is then taken out of service. Because of the stretch in the erase times, erase/free scheduling will also degraded over time. And a disk that is seeing accelerated use (lots of erase/writes) will display this performance decrease sooner.
Any questions?
http://img523.imageshack.us/img523/4225/image004ds8.jpg
Cody
I clearly stated that the blocks are never physically coherent after time, even if you reformat. It is the nature of the block related meta data. What I was trying to articulate is that fragmentation is a non-issue for SSD. There is zero seek delay and there is zero rotational latency. The only reason fragmentation matters in rotational media is that there is movement and settling time when you displace the heads, and there is rotational latency when you miss a block in track. Neither of these is an issue in SSD, so is just does not matter. Latency will NOT slow down the drive. All blocks are logically mapped, not physically.
What I did elude to were the issues on block reclaim and in particular erase delay issues on high erase count blocks. Rotating media does not have these reclaim/remap issues. Over time, the duration of the erase cycle goes up by a factor of ten. Hence, during heavy write activity on a fully loaded SSD, that is, one with a deficit of free blocks, the device will block on erase cycles. This will slow the write throughput.
which "they" does Intel mean?
" . . .the synthetic workloads they use . . . "
http://www.tomshardware.com/forum/248603-32-users-compare-benchmarks
http://www.experts-exchange.com/Storage/Hard_Drives/Q_24159694.html
Thanks All!
Robert
The 'latency' you mentioned above, is not write latency, it is free block starvation caused by block erasure timeouts. If you fill the disk to the point that you empty the free block table and have to wait for erase cycles, the write performance goes straight out the window. I have benchmarked this to a very fine degree as the firmware developer performing the device management on the NAND. Not from the OS side of the house, on the raw NAND. Do you understand? Free block starvation has no affect on read performance, just write.
The article is highly misleading. I do suspect that the issue is an Intel Firmware problem. Their implementation may have some value in special cases. It will certainly make efficient use of the part by more fully utilizing every block, but I fear they may have 'fancied' themselves into a corner.
Using normal logical/physical mapping, without small file gathering, I have never encountered any performance variation, regardless of block mapping, other than that caused by free block starvation.
Fragmentation never figured into it at all. Ever. Therefore, I highly suspect that the variation is all caused by the fancy footwork that Intel is doing inside their storage management. I also suspect that they will figure it out eventually. Do they support firmware upgrade in their controller? I certainly hope so.
Final statement. I said the erase time can go up by a factor of 10, not 100. Erase times are long in comparison to write times. I can write a full block group faster than I can erase that same block, when they are brand new. Near their end of life, I can write thirty or forty times as fast, because the erase time has stretched by a factor of 10. That kind of issue kills the free list, which kills write performance. I don't know how else to explain this, so I am done now.
For example, I bought a 60gb SSD and loaded windows7 beta on it to test it, it flies! I don't know how much is due to the new OS and how much to the increased read and write speeds of the ssd.
But windows boots up amazingly fast, and programs seem to snap open and slam shut almost instantly.
Can someone explain in laymans terms, what amount of performance degradation I will see on this ssd over say the next month, year, 5 years of normal use.
Aren't these suppose to last longer than physical hard drives in general?
And if they do slow down, are we talking unnoticable milliseconds here, or will they suddenly be slower than the physical hard drives they replace?
Thanks guys!
Anthony
http://forums.pcper.com/showthread.php?p=4351675
http://downloads.diskeeper.com/pdf/HyperFast.pdf
http://www.diskeeperblog.com/archives/2008/12/hyperfast_is_al.html
- by jfsog March 1, 2009 4:22 AM PST
- It seems to me that you can curb the slowdown potential of an as-new Intel SSD by creating a sizeable unformatted partition and never putting anything in that partition.
- Like this Reply to this comment
-
(25 Comments)Beating Performance Bogeys In Intel SSDs
http://selfdocumentingcode.blogspot.com/2009/03/beating-performance-bogeys-in-intel.html
Yes - you will still get some slowdown, but you can control the maximum slowdown by the size of the unused partition you set aside. Well - that's my theory anyway. Read the details in the preceding URL and let me know if it works for you. :o)