Comments on: Intel replies to solid-state drive 'slowness' critique

A technology review Web site claims Intel solid-state drives slow considerably after extended use.

[malynj]

Since there is a limit to the number of writes to flash, some (maybe most?) flash drives use a wear-evening technology to ensure that certain spots on the flash don't wear faster than other spots. It sounds like the technology used here for evening out the wear on the flash may be resulting in too much fragmentation over time. A read-ahead RAM cache might help some, but I don't know enough about these designs to know if they use that or would even consider using that to speed up any loss of performance from wear-evening fragmentation.

[HlLLARY CLITON]

Like Intel would admit their drives suck

[Bill_I]

This reminds me of the big denial that occurred when the Pentium coprocessor was shown to have an obscure arithmetic error. The users wouldn't have ANY errors, the press published some divisions to test, and the war was on. I tried it myself, the HP calculator got it right, Excel on my PC did not. Intel management should know better than to let PR flacks make pangloss statements before the engineers have done their homework and submitted a report.

[assman]

doesn't make any sense. if it were due to fragmentation, it would go back to normal speeds once it is reformatted. they seem to claim it is being permanently damaged, that if you were to buy a used one it would be slower than a new one. their reasoning doesn't make any sense. why would it physically be slowing down from use, even after a reformat or defragmentation is done?

[Talden]

Isn't it fragmentation in the Physical-logical mapping that manages wear leveling. Formatting the drive is just more writes (if anything that would worsen the situation) as is running a defragger.

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.

[catbutt5]

You know, when Intel released these drives, reputable reviewers were pretty clear that these SSDs featured algorithms that would tune the drive's performance over time depending on the workload observed.
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.

[zyxxy]

A couple of points here:

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?

[codynews]

No questions, but your user name reminds me of an old Vegas trip my friend and I took (we'd go every few months). We always passed this exit once we were about 30 minutes out from state line...

http://img523.imageshack.us/img523/4225/image004ds8.jpg

Cody

[smithrl]

Fragmentation can absolutely occur on a SSD. You have the cell size on the individual chips which is the lowest level cluster of data. To get higher speeds on SSDs they are multichannel devices, essentially acting as a RAID0 array; I believe the Intel drives are 10 channel devices. Depending on the file system cluster size you can create a lot of excess reads if the file system isn't aligned with the storage device. Because the drive does wear leveling and since currently OS is SSD aware I could see how things could get out of alignment causing slower performance issues.

[smithrl]

Meant to say NO OS or filesystem is currently SSD aware.

[Dango517]

Sure, Is Windows Readyboost actually an SSD driver? Are there GNU/free drivers to run USBs as SSDs? USBs are also NAND chips.

[zyxxy]

It is a reference to the Unix text game, adventure, that was popular (among Unix devs) back in the days of character displays. Think VT100 or VT220. There were a number of 'spells' in the game that were similar collections of zyx. I assume the road name is linked in some way.

[willdryden]

The command was xyzzy and it put you in the plover room.

[Eludium-Q36]

Two things bug me after reading: (1) the performance drop is never quantified either by percentages or other metric - so just how bad is the performance hit ?, and (2) will the Press ever stop referring to memory-based storage as "drives" ?! They should be referred to as MSAs (memory storage arrays) or SSA (solid-state arrays) though solid-state is such a '60s term. Happy Friday otherwise.

[zyxxy]

smithrl

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.

[smithrl]

The linked article wasn't talking about a increase in latency, but throughput. SSD latencies are so low to begin with even a 100 times increase isn't going to matter much. They article was stating how they believed cell level fragmentation was causing a large drop in write throughput and less so. read throughput.

[scottthesculptor]

There are far more than one tech site that show that the Intel SSD slows down considerably over time - a short period of time under test conditions.


which "they" does Intel mean?
" . . .the synthetic workloads they use . . . "

[bzowk]

I am researching this issue with my X25-M drive. Please see my two following posts regarding this issue.

http://www.tomshardware.com/forum/248603-32-users-compare-benchmarks

http://www.experts-exchange.com/Storage/Hard_Drives/Q_24159694.html

Thanks All!

[Heebee Jeebies]

On the other hand why didn't the reviewers just use the device in normal day to day use. Why did they have to fake test it. Makes one wonder about their testing. It should be a simple matter to install the things and use it day in and day out like a normal person for a month or two and see how it does. Benchmarks are worthless, real world, real use is what matters not fake accelerated testing. This goes for ink and paper life span claims as well. When we have an ink jet print that hasn't faded and is 50 or 75 years old then we can talk about fading and permanence. Until then it is all poo!

Robert

[zyxxy]

Okay. Back to square one. It is not (not not not not not) a fragmentation issue. Fragmentation in NAND is a non-issue. It is an Intel Firmware issue. It has no relation to NAND fragmentation. Yes, I read the whole article. It has a a lot of misleading statements. I have written NAND block drivers to emulate SCSI attached storage myself. I know how NAND works internally. I know how the meta data gets used.

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.

[smithrl]

The Intel drives have only been out for a few months. Even under their accelarated use I don't see how they could of started causing the MLC to start having loads of write failures and much increased erase times. My point was with file system/cell level alignment can cause an increase in read/write throughput. I understand you have to go through an erase cycle before you can write. My point was that file system / storage device alignments can affect the throughput regardless of storage technology used and that is a form of fragmentation.

[smithrl]

I meant to say block level alignment, not cell level alignment.

[AnthonyNYC]

I wish someone would explain what this all means to us who are using new SSD's as far as performance levels over the next few years.
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

[SerengetiValley]

I doubt if they will be slower than the HDDs as far as read performance is concerned, because seek times for SSDs are very low. Random writes can be slow in SSDs (slower than HDDs? I don't know for sure, but I don't think so) and this coupled with internal 'fragmentation' of the SSDs (not file system fragmentation) can cause slower writes because unlinke HDDs, there is an erase/write cycle for SSDs. Over a period of time, as free space gets fragmented in the filesystem, more and more number of I/O requests need to be issued to write a (fragmented) file resulting in slower random writes. Consolidation of free space at the file system level helps greatly by reducing the number of I/O requests from the files system when writing a file.
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

[jfsog]

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.

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)