Flash Destroyer Tests Limit of Solid State Storage

An anonymous reader writes "We all know that flash and other types of solid state storage can only endure a limited number of write cycles. The open source Flash Destroyer prototype explores that limit by writing and verifying a solid state storage chip until it dies. The total write-verify cycle count is shown on a display — watch a live video feed and guess when the first chip will die. This project was inspired by the inevitable comments about flash longevity on every Slashdot SSD story. Design files and source are available at Google Code."

Comments

Interesting!

[exasperation]

It'll be nice to get some third-party data on exactly how long these things last on average.

Re:Interesting!

[mantis2009]

Just checked out the video feed. The chip already lasted longer than 1 million writes, which is the number of writes the chip is supposed to last over its lifetime. As of this writing, the chip has survived more than 1,600,000 write cycles and counting.

Still, since this test isn't on an actual, shipping solid state drive (SSD) product, the results will be discounted by a lot of critics.

Re:Interesting!

[Anonymous Coward]

Yes, its nice to finally get some independent data on this. It would also be nice to try this tool on spinning platter disks. People tend to forget that they also only endure a limited number of cycles. From what I remember from the time before spinning platter disks had wear leveling implemented the number of writes was way lower than that of modern flash memory. (Or perhaps I was just unlucky.)

Re:Interesting!

[Smallpond]

Mechanical disks have lots of great failure modes. You can do seek tests until the arm breaks or voice coil fails, you can do write/read tests until you get enough bad sectors that they can't recover the data any more, or you can do start-stop of the drive motor until it dies. Another good one is to stop the motor for a while, then see if it starts up or has stiction (sic), but that test takes a long time. If the drive is not held rigidly enough, vibration will kill it, and it it isn't cooled properly, heat will kill it. Did I miss any?

Re:Interesting!

[Sponge Bath]

The rated write cycles may be at the extreme of the rated operating temperature. He needs to bake the test rig in an oven for the duration of the test.

Re:Interesting!

[jellomizer]

I would like to see a comparison with a mechanical drive doing the same thing in parallel.

While the Solid Sate has a theoretical Limited number of writes vs. the mechanical drive, it would be interesting to see what real world has to offer.

Re:Interesting!

[quercus.aeternam]

I vaguely recall reading that the more writes flash has, the less likely it is to remember what is written to it over time - kind of like volatile storage, but with the length of time the data lasts being inversely related to the number of writes.

Given what I know about flash, I'm not quite sure how this could happen physically. I believe this was mentioned when I was looking into ssd caches for zfs, where this type of failure would be insignificant. It could be completely incorrect, too.

If it is correct, this sort of test alone will not be definitive. Instead, a batch of chips would have to be written to different levels, and then periodically verified.

Re:Interesting!

[msauve]

since this test isn't on an actual, shipping solid state drive (SSD) product, the results will be discounted by a lot of critics.

Assuming that the flash is of equivalent technology (e.g. SLC NAND, cell size, etc) to that used for SSD, then this would present a best case test, since it is exercising all cells equally.

An SSD tries to do wear leveling (distribute writes evenly), but that can't done perfectly, as is done in this test.

Re:Interesting!

[Dancindan84]

And honestly it's a pretty valid argument. This is definitely going to be informative, but I'm just as interested in how a particular SSD handles the flash blocks failing as when they fail. A SSD with flash that averages 1,000,000 writes before blocks start to fail but does it gracefully with little/no data loss could be better than one that averages 2,000,000 but goes out in a blaze of glory as soon as the first block fails.

Re:Interesting!

[Kindgott]

Yeah, the title seems misleading, since they're writing and verifying data on an EEPROM, which is not used in solid state drives last time I checked.

Re:Interesting!

[Anonymous Coward]

Yea, you missed one.

What happens if you pee on it?

Re:Interesting!

[Pharmboy]

Or connect the drive inside any computer running a Prescott P4 with 100% CPU utilization.

Re:Interesting!

[D Ninja]

If you have any important data on that drive, urine trouble...

Re:Interesting!

[Flea of Pain]

Just one...you can blend it.

Re:Interesting!

[InsaneProcessor]

I find this "not very interesting" RTFA. This is not a flash destroyer. It is an EEPROM destroyer. NOT THE SAME THING AND NOT USEFUL!

Re:Interesting!

[beaviz]

Did I miss any?

Oh yes!

Can it be overloaded with excessive amounts of (bad) porn?
How long will it survive in the hands of a 2-year old?
What will happen if it were to meet the goatse-guy in a dark alley?
Can you eat it?
What will happen if you leave it in the microwave oven for too long?

Hmm. I should go to bed.

Re:Interesting!

[Anonymous Coward]

You're wrong, twice. Almost all consumer SSDs use MLC (eg the X-25, nearly all products based on the Indilinx or Sandforce controllers). Also SSDs ship with a few gigabytes of extra space for wear leveling; available sectors just get lined up neatly in a queue (according to whoever has had the least write cycles so far) and the controller picks the sector at the top of the list. The absolute worst-case scenario is that someone will fill up the entire drive and then write to the same spot over and over again; even in this extreme corner case, wear-leveling algorithms are "perfect" in that they will distribute the writes 100% evenly across all available spare sectors until one of them dies (at which point it *should* repeat the process with the remaining sectors, until they're all gone too).

Re:Interesting!

[glwtta]

I'm just curious, why use sic in your own posts? Wouldn't you just correct whatever you are sic-ing?

Re:Interesting!

[TeknoHog]

I'm just curious, why use sic in your own posts? Wouldn't you just correct whatever you are sic-ing?

IMHO, this kind of use of [sic] is perfectly valid. It means "this is not a typo, it's really how it is spelled" (literally "thus"). In this case it refers to an unusual word that may look like a misspelling of a more common word. However, it can also refer to a genuine misspelling, when you are referring to what somebody else wrote.

Re:Interesting!

[Chris Burke]

A SSD with flash that averages 1,000,000 writes before blocks start to fail but does it gracefully with little/no data loss could be better than one that averages 2,000,000 but goes out in a blaze of glory as soon as the first block fails.

That depends on how you define "better", and for my personal definition, it depends on exactly how glorious a blaze it is. :)

Re:Interesting!

[BikeHelmet]

Just checked out the video feed. The chip already lasted longer than 1 million writes, which is the number of writes the chip is supposed to last over its lifetime. As of this writing, the chip has survived more than 1,600,000 write cycles and counting.

Still, since this test isn't on an actual, shipping solid state drive (SSD) product, the results will be discounted by a lot of critics.

This destroys EEPROM - not NAND flash.

Based on all the people RMA'ing SSDs in the 12-24 month range, I'm betting the number of actual write cycles is significantly below the number of theoretical write cycles.

Re:Interesting!

[Anonymous Coward]

SSDs fail on write, but you can still read the data back, so how "catastrophically" it fails is not even a problem. Unless, of course, the controller dies.

Re:Interesting!

[gumbi west]

According to the article, flash is a type of EEPROM, so what is the problem?

Re:Interesting!

[Sinning]

Isn't that what the OP said?

Re:Interesting!

[Jah-Wren Ryel]

And honestly it's a pretty valid argument. This is definitely going to be informative, but I'm just as interested in how a particular SSD handles the flash blocks failing as when they fail. A SSD with flash that averages 1,000,000 writes before blocks start to fail but does it gracefully with little/no data loss could be better than one that averages 2,000,000 but goes out in a blaze of glory as soon as the first block fails.

Flash fails on write - if the write succeeds, you will be able to read it baring catastrophic events like ESD exposure.

Re:Interesting!

[gumbi west]

This is a test of a single EEPROM, there isn't really a magnetic equivalent. It's part of why routers et cetera all use flash (a type of EEPROM) instead of magnetic hard drives, you can have a 4 MB flash, but not so economical for magnetic hard drives.

Re:Interesting!

[msauve]

So, I'm violating my usual rule of not responding to ACs, only because you're such an idiot (which conveniently explains why you are posting AC).

"perfect" in that they will distribute the writes 100% evenly across all available spare sectors

See, that's the thing. Once a sector is written to, it won't be touched again, unless the data changes. You end up with some subset of sectors which are frequently modified, while others never are. That is NOT an even distribution of writes across all sectors, nor is it "perfect" in any sense of the word.

So, fill up 75% of your SSD with files which don't change, then beat up on the remaining sectors 4 times as much as truly evenly distributed writes would cause.

It's not clear what you "MLC" comment was about, since I specifically mentioned that as an example of flash technology.

Re:Interesting!

[lauragrupp]

Here is work from the academic community exploring error rates, latencies and some other factors. It compares 11 NAND flash chips (both SLC and MLC) from 5 manufacturers: http://nvsl.ucsd.edu/ftest.html

Re:Interesting!

[Anonymous Coward]

Typically flash chips are shipped with bad blocks already on them. When they say 1,000,000 write cycles, it is caveatted with a number of blocks you should expect to go bad within that time frame. Also, when a block goes bad, it's not like it melts. It just means that you will get more bit errors than can be corrected based on its specifications. How that affects the data stored in there depends on what it is ... if it is a .wav file, no biggie, you'll just hear a blip. If it is used as a swap file, well, you very well may get an explosion.

Re:Interesting!

[Sancho]

All who? Any citation on large numbers of SSDs failing between 1 and 2 years?

Re:Interesting!

[h4rr4r]

All what people?
My dell mini 9 is that old if not older and still no issues. I have no swap partition though and I put firefox cache and tmp on a tmpfs.

Re:Interesting!

[Rockoon]

A SSD with flash that averages 1,000,000 writes before blocks start to fail but does it gracefully with little/no data loss could be better than one that averages 2,000,000 but goes out in a blaze of glory as soon as the first block fails.

Just so that you are aware,

1,000,000 is a large number if you mean writes-per-block. You will never wear out such an SSD unless its very very small. Lets consider a 32GB SSD that can write 250MB/sec as an example (this would be the highest of the high end ~32GB SSD's) It will take 128 seconds to write 32GB of data to it. With 1 million write cycles thats 243 years and 133 days of full blast writing in order to wear that monster out.

1,000,000 is a small number if you mean writes-in-general. There would already be plenty of stories about these things dying prematurely if that were the case.

While the 10,000 write cycle limit of MLC may be an overstatement, it can't be that much overstated because there arent reports of people killing their OCZ/Intel drives.

Re:Interesting!

[Anonymous Coward]

LOL. That didn't used to be the case. My first HD was 20 MB. ;^) And back then you just couldn't imagine what a 20 MB EEPROM would have cost.

Re:Interesting!

[Rockoon]

Mechanical disks have lots of great failure modes.

My favorites are the ones that make loud sounds during the failure event. When a piece of the head breaks off, for example.. that thing bounces around in there like crazy when the drive is spinning around thousands of times per minute.

Re:Interesting!

[w0mprat]

At maximum write speed it may take a decade to destroy a SSD with wear leveling. So this kind of testing is still irrelevant in real world.

At 100mb/s it takes 10 minutes to write to every block once on a 64gb SSD, it would take 19 years to complete one million write cycles on every single flash cell.

It is impossible to test a whole SSD in real world scenarios, because the flash may outlive the circuity controlling it (especially flaky RoHS compliant crap) and in a decade or more your test is irrelvant. They could test to destruction a single flash chip however, but this helps little for someone trying to gauge whether a SSD is any good. Chip makers obviously test individual chips and use statistics to estimate lifetime of a SSD product, but nobody can say for sure what happens in 5-10 years time.

(But yes it is possible varying quality in mass producted flash may cause some blocks to fail prematurely of course, then wear-leveling and spare-block allocation has to demostrate it's stuff).

Re:Interesting!

[Loki_1929]

He said an oven, not a nuclear fusion core.

Re:Interesting!

[Anonymous Coward]

Mechanical drives usually has a much lower number of writes before failure but they have finetuned their wear leveling for a couple of decades now.

Re:Interesting!

[BikeHelmet]

I just hang around on the NCIX forums, and every day or two there's a person complaining about having to RMA their SSD because programs started crashing, and then finally they couldn't even boot it.

I saw lots of people replying in threads, saying theirs were still working fine. I started asking everyone how long they had owned theirs. Most with working SSDs were in the 8-15 months range, and most with serious problems were in the 12-24 months range.

I've noticed that SSD warranties from a lot of manufacturers have dropped from the original 5 years down to ~2. That's quite a drop. There must be a reason.

I suspect a heavy disk user like myself would burn through one well before the warranty is up.

Note: My sample is pretty small compared to the amount sold, but I do wonder how many die without the owners being vocal about it.

I'm wondering if close to two years ago manufacturers flipped to cheaper NAND to get the prices down? Now prices are going back up, so maybe manufacturers realized their mistake? Even since January, SSD prices have gone up 20-30% on average. $89.99 SSDs are now $120+

http://www.newegg.com/Product/Product.aspx?item=N82E16820167025&Local=y

Re:Interesting!

[coolgeek]

Except this video (according to the title of the page) is about EEPROM longevity. Flash != EEPROM

Re:Interesting!

[gyrogeerloose]

When I first read the title of the summary, I thought to myself "Shit, yet another one about Apple versus Adobe..."

Re:Interesting!

[mirix]

That's assuming that every data write is immediately read back and compared to the written value... I don't believe that's standard procedure?

Although perhaps the SSD controller compares buffer to write val, and if it fails, marks the sector bad and writes it somewhere else, transparent to the OS. They must have something like that...

Re:Interesting!

[gyrogeerloose]

That depends on how you define "better", and for my personal definition, it depends on exactly how glorious a blaze it is. :)

Really. Don't all of us Slashdotters love a good explosion? Sure, we mostly prefer them to be scheduled explosions but, still, an explosion is an explosion.

Re:Interesting!

[dave420]

The chip in question is completely different in tolerances, performance, and life-span of the chips used in SSDs. That's the problem.

Re:Interesting!

[gyrogeerloose]

From A Dictionary of Modern American Usage:

Sic (=thus, so), invariably bracketed and usually set in italics, is used to indicate that a preceding word or phrase in a quoted passage is reproduced as it appeared in the original passage. Sic at its best is intended to aid readers who might be confused about whether the quoter or the quoted writer is responsible for the spelling or grammatical anomaly.

You should therefore position [sic] straight after the error to which it refers: if a misspelling, after the word concerned; otherwise after the phrase.

I'm not sure his usage exactly conforms to that but, in any case, it's not really horrible.

Re:Interesting!

[PopeRatzo]

So I guess this means we have to back up our data. Did anyone think that flash drives were going to make backups a thing of the past?

Personally, I'm using SSDs for system drives and one for streaming video and music samples to my editing software. In both cases, the data on the disks is safely archived. But I get a nice bump in performance, or so it seems (since I haven't done actual measurements and only have my subjective experience to go by).

Even with the scary suggestions about durability (relative to spinning platters, I guess) which may or may not turn out to be true, I'm glad to have these SSD drives. When they get cheaper, I'll be using a lot of them.

Re:Interesting!

[Anonymous Coward]

Most Flash drives will invisibly assign the writes to new sectors as they notice one sector starts getting "beat up" on. The wear leveling is quite advanced.

Re:Interesting!

[Simetrical]

So, I'm violating my usual rule of not responding to ACs, only because you're such an idiot (which conveniently explains why you are posting AC).

"perfect" in that they will distribute the writes 100% evenly across all available spare sectors

See, that's the thing. Once a sector is written to, it won't be touched again, unless the data changes. You end up with some subset of sectors which are frequently modified, while others never are. That is NOT an even distribution of writes across all sectors, nor is it "perfect" in any sense of the word. So, fill up 75% of your SSD with files which don't change, then beat up on the remaining sectors 4 times as much as truly evenly distributed writes would cause. It's not clear what you "MLC" comment was about, since I specifically mentioned that as an example of flash technology.

So keep track of how many times each erase block has been written, and if some blocks get erased too often relative to the rest, move data from the least-erased blocks onto the most-erased blocks. You do a few extra writes this way, but a negligible number if you set the thresholds high enough. And then you'll get fully leveled writes. I'm sure the clever folks at places like Intel have figured out strategies like this (although for the cheap stuff, who knows).

Re:Interesting!

[Anonymous Coward]

You must have a lot of friends.

Re:Interesting!

[srvivn21]

Not the original AC, but I thought I would try to clear up a disconnect instead of downmodding...

So, I'm violating my usual rule of not responding to ACs, only because you're such an idiot (which conveniently explains why you are posting AC).

-1 Flamebait. As I'll show, the rest of your rant has insufficient content to balance this.

"perfect" in that they will distribute the writes 100% evenly across all available spare sectors

Emphasis mine.

See, that's the thing. Once a sector is written to, it won't be touched again, unless the data changes. You end up with some subset of sectors

The spare ones, as the AC pointed out.

which are frequently modified, while others never are. That is NOT an even distribution of writes across all sectors,

Not a claim made by the AC.

nor is it "perfect" in any sense of the word.

Strictly your opinion.

So, fill up 75% of your SSD with files which don't change, then beat up on the remaining sectors 4 times as much as truly evenly distributed writes would cause.

The AC actually posited a worse case scenario, in that the whole disk was filled, and only one "spot" was repeatedly changed.

It's not clear what you "MLC" comment was about, since I specifically mentioned that as an example of flash technology.

Sorry mate, your original comment made mention of SLC, not MLC. While it's not clear what the AC was harping about (as you didn't make a claim regarding the type of flash used by retail SSD's) calling the AC names without comprehending what was actually written is not conclusive to a rational discussion. I can only hope I'm not feeding a troll.

Re:Interesting!

[aix tom]

Flash is an EEPROM. A special kind of EEPROM.

One main difference being that you can't write single bytes or bits like with other kinds, you have to always write entire blocks.

Re:Interesting!

[queazocotal]

You are implicitly assuming that the wear leveling algorithm spans the whole device.

That is - a write to block 407 will have the wear evenly distributed.

There are several issues here.

Firstly - eraseblocks are typically around 150K or so.

Secondly - http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg170028.html - many flash devices may wear level only on 'zones'. So a write to block 407 may only wear level across .5% of the device.

Doing the wear leveling this way drastically reduces the amount of CPU and other data storage you need to keep track of where the blocks are.

The OLPC project http://wiki.laptop.org/go/NAND_Testing#SD_Cards - did some interesting tests, writing and rewriting two 20M files.
This failed in one SD of 6 tested, at 16terabytes written.

The wear leveling algorithms of 99.9% of flash devices are not public. You don't know what the wear leveling span was in the above test. It may reasonably have been a thousand eraseblocks - 130M or so.
This will mean that the actual writes per block were on the order of 12 million.
This is not a completely surprising number to me for the ~5% of the spare blocks in the wear leveling block to have been used.

Unfortunately, the secrecy means that the chip you order next week may perform differently.

Re:Interesting!

[networkBoy]

And in fact, the more advanced wear leveling algorithms do this already. There are spare blocks specifically such that the data can be moved, then the old block that was not used can be freed.

Re:Interesting!

[networkBoy]

In fact, they are read back. At the flash component level.

The flash cell is a charged gate. when programmed the uC in the flash device compares the charge state with a reference voltage. Not enough? Add more charge. Still not enough? Cell is bad, mark it (block level, so you lose xx bits for one bad one) and move on.

This is fairly high level and not exactly how it works, but close enough.

Re:Interesting!

[gumbi west]

Except that it is rated at 1M read/writes. Theoretically, they could test any EEPROM that they could get hooked up (this one is 128-bits, I would guess that this the sort of size that is applicable). If they could get one from a manufacturer... they could test it with this rig.

Re:Interesting!

[gumbi west]

"It is impossible to test a whole SSD in real world scenarios"

Nah, you hook it up, do constant read writes and wait until it fails. If it takes more than a few years (as you claim) then that's a pretty good indication of what one might expect. On the other hand, if it doesn't, you got to start worrying.

Re:Interesting!

[mysidia]

He said an oven not a nuclear fusion core.

The response was a Prescott P4 at 100% CPU, not an SCC / 48-CORE Intel Many-Cores(TM) chip with all cores at continuous 100% utilization

Re:Interesting!

[blahplusplus]

One should not forget companies might have "chip lotteries", i.e. use chips that are less robust and cheaper to manufacture without majority of consumers knowing the difference.

They do this in the LCD monitor industry where they have "panel lotteries" that use cheaper parts and are not what is advertised due to consumer ignorance. See Article on Anand here about panel lotteries:

http://forums.anandtech.com/showthread.php?t=39226

Re:Interesting!

[mysidia]

See, that's the thing. Once a sector is written to, it won't be touched again, unless the data changes. You end up with some subset of sectors which are frequently modified, while others never are. That is NOT an even distribution of writes across all sectors, nor is it "perfect" in any sense of the word.

If you have a copy on write filesystem such as ZFS, changes might be written to new blocks.

It seems that in the future storage agents (or the SSDs themselves) might eventually evolve to relocate certain regions physically, in order to put rarely written data, or data that is 'stable' due to the existence of snapshots, onto the most worn sectors.

Once wear on the commonly written sectors exceeds certain ranges...

Re:Interesting!

[Anonymous Coward]

Actually, I believe *you* are incorrect. Different AC here, but I had to respond because your response doesn't match what I understand to be the case as an engineer working with vendors selecting NAND flash for use in consumer devices. I'll be interested to see if I'm incorrect or if this even gets read as an AC post.

Specifically, it doesn't matter to the flash device if the host has written a sector and never touched it again, that sector *will* be moved when it's been read enough times that the ECC indicates it's likely to become unreadable soon. This is called read disturbance and it can happen surprisingly frequently with MLC cells in small process sizes (i.e. at sufficient density to make multi-GB modules). It also happens on SLC devices but to a lesser extent because they can cope with more voltage decay per bit and still be able to read the bit correctly. This is done as a function of even the simplest block-access controllers because otherwise you wouldn't be able to read your own data back more than a few hundred times. In fact, if you wish to get technical about it, it also has a massive dependency upon the temperature the module is at when the data was originally written since this directly impacts the amount of electrons which can be stored.

In addition to moving data to counter read disturbance, most controllers (even the very simple ones in SD Cards & eMMC devices) will move sectors (actually not filesystem sectors, but individual blocks although the distinction isn't important here) around in order to optimise wear across the entire device even if the content hasn't changed. If you think about it, this has to happen at some level even without wear levelling since the sector is massively smaller than the superblock size for most of the densities we have available today - it's not unusual to see a device with an erase block size of 256KB, which is normally way larger than a sector.

I don't know much about SSD controllers, they're far too expensive for our devices, but they can't possibly work the way you think they do - not if they use the same raw NAND that is used for other block storage abstractions.

Re:Interesting!

[Anonymous Coward]

Informative? How about wrong!
128seconds *1M operations = 128,000,000 seconds
Seconds in a day = 86400
128M/86400 = 1481.48 days

Or roughly 4 years.

For some reason, you divided 128M by the number of minutes in a day (1440) to arrive at your ludicrous 243years.
Hence you are out by a factor of 60.

Re:Interesting!

[Anonymous Coward]

I'm personally convinced it's just another round of Memory Company Collusion, like the whole rambus thing.

Honestly the price of ALL memory has gone up between 20 and 100 percent in the past year (go look at ddr2/ddr3 prices, they're the same or HIGHER than they were last year. 4 gigs for 50 bucks a year ago, 2 gigs for 45 bucks now. There was an overlap period on newegg where UNREGISTERED ECC DDR3 @ 1333 was CHEAPER than Non-ECC consumer sticks by 10-20 bucks for the same capacity. Obviously that has since changed, but the point is memory is suspiciously going up in price while most other consumer hardware is still on the way down.)

Re:Interesting!

[arth1]

It's worse than that too. His example presumes perfect wear leveling, which is only attainable if you delete everything you write to the drive, and don't have any static content. Cause wear leveling only picks another sector to write to from among the unused sectors. Simplified, if your drive is 80% full, you write to the same sectors five times as often.

Sure, wear leveling could read static content and write it out somewhere else, freeing up the block the static content had, but that would both reduce the speed of the drive (it might be busy moving stuff around), and in itself cause extra writes, thus reducing the overall lifetime.

I have a small stack of failed SSD drives. Mostly MLC, but a couple of SLC too. All in all, I find them no more reliable than HDDs, and for MLC drives, less. Especially because once blocks start failing, other blocks start failing too, at an accellerating rate, and they rapidly reach a state of being completely unusable. A HDD, on the other hand, can often mark off the bad area of the disk and continue to run well for years (and in some cases, decades).
What's nice about SSDs is speed, period. Especially sequential speed, making them an excellent choice for jobs where bandwidth matters.

Re:Interesting!

[Eskarel]

Which is still longer than most consumer grade static drives will give you, and when those fail you can't read from them.

Presuming you don't buy a drive which is far too small for your needs and you don't have particularly odd usage patterns(SSD's don't have particularly good performance on large sequential reads so sticking your movie collection on them is fairly worthless), the average SSD will likely outlast the average HDD.

Re:Interesting!

[Anonymous Coward]

Also puns [sick].

Re:Interesting!

[Bob_Geldof]

I'm personally convinced it's just another round of Memory Company Collusion, like the whole rambus thing.

Honestly the price of ALL memory has gone up between 20 and 100 percent in the past year (go look at ddr2/ddr3 prices, they're the same or HIGHER than they were last year. 4 gigs for 50 bucks a year ago, 2 gigs for 45 bucks now. There was an overlap period on newegg where UNREGISTERED ECC DDR3 @ 1333 was CHEAPER than Non-ECC consumer sticks by 10-20 bucks for the same capacity. Obviously that has since changed, but the point is memory is suspiciously going up in price while most other consumer hardware is still on the way down.)

Have you taken into account the difference in inflation of your local currency and that of the currency used where the RAM in question is made? Assuming a Taiwanese manufacturer selling in the US, my back of the envelope calculations put a $50 quantity of RAM last year at most $53 today due to exchange rates. Add on another 2% for inflation (http://forecasts.org/inflation.htm) we get $54.

Then again that does not take into account the dip in supply as a result of manufacturers holding off production while the western economies tanked over the last year or two. It comes down to how accurately did the manufacturers predict the drop in demand. It is possible demand exceeds supply enough to increase prices by about $5-$15 at the moment.

I think it is plausible that we are only seeing market forces at play here. Someone should look into it a bit more though, to be sure.

Re:Interesting!

[Tablizer]

it depends on exactly how glorious a blaze it is

Maybe Trek's sparking consoles have something to them after all.

Re:Interesting!

[Polymorph2000]

Actually there is magnetic equivalent: http://www.ramtron.com/products/nonvolatile-memory/serial.aspx

F-RAM comes in an SOIC, so you'd have to solder some wires to the "Flash Destroyer" board.

Re:Interesting!

[Bing Tsher E]

That brings to mind an old favorite of mine: the Light Emitting EPROM. The power pins on EPROM chips are in opposite corners. Plug in the EPROM chip backwards and you've hooked the power up backwards. Result: A light emitting EPROM, though one with a very limited service life.

Re:Interesting!

[Bing Tsher E]

Ramtron must have changed, then. I had F-RAM samples from them in the early to mid 90's that were in a DIP package. I suspect they're still available in that package if you ask...

At the time we went with EEPROM. The FRAM stuff was too new in 1994 to get into a medical device, at least where I worked at the time.

Re:Interesting!

[Bing Tsher E]

The wear leveling algorithms of 99.9% of flash devices are not public.

When you're posting a comment where all the other numbers you're using are fairly meaningful, you shouldn't drop something like this in the middle of your post. It just looks dumb. There aren't 1000 different vendors of Flash Devices, and there isn't one vendor whose algorithms are published.

They're all pretty much considered trade secrets at this point. It's an area of technology still in it's infancy. Give it another decade. (it's refreshing that at least SOME areas of electronics don't 'roll over' every six months.)

Re:Interesting!

[Bing Tsher E]

In common usage in the electronics industry, EEPROM memory is one particular thing. Flash memory is something totally different. We might as well go all pedantic, I guess, and say that it's all RAM memory, since you can access random locations arbitrarily.

Re:Interesting!

[izomiac]

Cause wear leveling only picks another sector to write to from among the unused sectors. Simplified, if your drive is 80% full, you write to the same sectors five times as often.

Especially because once blocks start failing, other blocks start failing too, at an accellerating rate, and they rapidly reach a state of being completely unusable.

That's a contradiction. If the wear-leveling algorithm was ineffective then you'd have a relatively constant rate of block failure. A good wear-leveling algorithm ensures you won't get a significant number of block failures until almost every block has been worn out. Then you get a bunch. So the behavior described is failing exactly as intended, and indicates the wear-leveling algorithm worked almost perfectly.

But you're right in that a wear algorithm that only uses free space would be terrible. That's one reason no device uses one like that. The primary reason though, is because the SSD has no idea which blocks are empty and which are free, unless it is told via the TRIM command (later generation SSDs with newer OSes). The filesystem knows, but an SSD is filesystem agnostic. Moving data is the cause behind the performance drop-off when the drive runs out of unused/un-TRIM'd blocks.

Personally, I have the cheapest, buggiest SSD in common knowledge (the one that can get bogged down to 4 IOPS), and it has worked beautifully for me. Just checking a diagnostic tool, in the past two years I've power cycled it 5,666 times (which probably explains why I kill HDDs so quickly), the average block has been erased 7,333 times, and no block has been erased more than 7,442 times. I've got zero ECC failures. Honestly, I'm a little surprised I've written 234 TB of data to my poor 32 GB drive, but my usage is a bit heavy (~10 complete Gentoo compiles with countless updating, ~5 DISM'd Windows 7 installs, ~5 DISM'd Vista installs, ~30 Haiku installs, ~20 SVNs of 10 GB projects, and a good amount of downloading).

But, in my experience, the wear leveling algorithm is only ~3% away from being "perfect".

Re:Interesting!

[ksandom]

This is when they discover that they were actually writing to /dev/null

Re:Interesting!

[queazocotal]

By volume sold, I was meaning.
There are a half-dozen at most high volume vendors.

The nokia N900's root filesystem is ubifs - and hence the wear leveling algorithm is public - this is part of the .1%

Re:Interesting!

[hitmark]

crashing, boot? sounds more like read errors (corrupt data) then a out and out write failure.

And that can just as well be bad cabling or controller (or something other odd, i had a HDD that would corrupt the file system on me under win98, but when i switched to win2k it stopped. to this day i am unsure about the actual interactions that would cause it).

Re:Interesting!

[hitmark]

just dont call done on the first write error, as that can be a bad component. When it happens repeatedly, you probably have hit the point of no return.

Re:Interesting!

[jridley]

How is that offtopic? Crazy mods.

Re:Interesting!

[Anonymous Coward]

Which goes to show how 1-sample statistics are great hype and no content...

Re:Interesting!

[bami]

I think the P4 has a nuclear fusion core embedded into it.

Temperatures of 100 oC with the stock cooler? NO PROBLEM!

Re:Interesting!

[DamonHD]

Hmm, yep, done that back in the days when a 2kB EPROM (with ~250nS cycle time for a 4MHz Z80A M1 cycle IIRC) was big and expensive.

But (a) I think it was the little interconnect wires that were glowing, and (b) I seem to remember that the EPROM worked afterwards. I think I did it at least twice. And didn't have to own up.

Rgds

Damon

Re:Interesting!

[dgatwood]

You're right that this doesn't provide any useful data about real-world drives at all because the technology is completely different (the EEPROM probably uses SLC NOR flash judging by the write cycle count in its specs, while as you said, most SSDs use MLC NAND flash parts).

However, the GP post did not say or imply that SSDs used SLC parts. The post said that this was roughly a best case for SSDs that used the same flash tech as the part being tested (with SLC being an example), meaning a test against SLC parts is valid against other SLCs. That's not entirely correct, of course, because of the presence of spare parts and significant differences in the longevity of flash parts from one manufacturer to another, variation between parts, etc., but it is still interesting.

Also, the question of wear leveling is completely irrelevant. This still provides a close approximation of the best case for that particular flash part, and you can multiply by the number of flash parts to get the best case for any device that uses such a part. The very definition of an erase cycle count for the entire drive, by its very nature, takes into account perfect wear leveling. A drive with an erase cycle count of 1,000 means that on average, every cell has seen 1,000 write/erase cycles. In perfect wear leveling, that means you've written and erased 1,000 times the capacity of the drive. In less than ideal wear leveling, it is less than that. And, of course, for writes that only change bits in a single direction (the direction being different for NOR vs. NAND), you might get a few extra write cycles once in a while, but that's likely to be so rare in real-world use that it's almost not worth mentioning. Thus, this does, in fact, as the GP indicated, provide a fairly good best case bound for the reliability of the particular device in question, were it used in any sort of SSD.

I'd love to see this test repeated with MLC NAND flash parts. I think the results would be eye-opening.

Re:Interesting!

[Anonymous Coward]

The technique you are referring to is known as dynamic wear leveling. The technique that alleviates this is known as static wear leveling.

Re:Interesting!

[Anonymous Coward]

One time I had a 10GB IBM harddisk (351010 something) which I mounted at a 45-ish degree in the computer enclosure, on the edge hanging by its IDE cable (No, I didn't really think it through. What happened is not what I expected to fail though). At one moment when it was suspended with its controller chip just over the upstanding edge of the bottom of the enclosure (the part that the side grips into) there was a spark from within the controller chip to the side of the enclosure, ripping the chip open & letting the white smoke out with a flash and a bang.

Never saw any data again, controllers were nigh to be unfindable and I had to mess with a bios that couldn't handle the new 40GB disk that I bought to replace it, but the story already lasts 10 years or so - much better than the 2GB Seagates (3.5") that I had that went out as a dud.

Re:Interesting!

[gumbi west]

Unless you use RAID 3, 4 or 5, then your array would be toast. But O/W, it's just limping.

Re:Interesting!

[AaronLS]

It's not a single chip that is supposed to last a million cycles, but a single sector, unless you wrote to the entire chip in one cycle. I'm really curious about what the counter is actually counting. We would need to know some more details about how the chip is being written to to determine if this is a count of writes across the chip, or if they are to a single sector. What if they are writing a single byte repeatedly, then a 1gb chip+wear leveling could sustain something like 1,000,000,000,000,000 writes, (1,000,000,000 bytes each written to 1,000,000 times). I'm sure there is more to it than that. My point being the methodology of this experiment is unclear to me. I didn't see any information on the live stream site that linked to any information on the methodology.

Re:Interesting!

[AaronLS]

Ok, so I didn't reallize a different link explained what was going on... "A PIC 18F2550 fills an EEPROM with values, and then verifies the content. Each successful write-verify cycle adds one to the counter display." So each count represents all sectors having successfully been written to. So this is a pretty great test, since it will show us how long until the first sector fails. This actually means a larger chip would be more likely to fail sooner because more sectors would mean more opportunities for failure.

live stream

[Anonymous Coward]

a live stream linked on slashdot.. ouch..

Re:live stream

[biryokumaru]

They should have a bit torrent-like system for streams. Like, you just connect to the swarm and request a fairly recent image. Everyone keeps the past minute or so cached to send to new people in the swarm. Maybe a tiered system so that the people who have been connected longest are closest to the original stream.

Let's say I connect to Joe and Mary, who're connected to the original server. They send me frames two or three frames behind the server. Jack connects, and he's getting a bit lagged images too, right with me. Now Sally connects and she's behind me and Jack, so Me, Jack, Joe and Mary all send her images. It's like a pyramid scheme for streaming video.

Now Joe leaves. I've been around longer than Jack, so I move up in the tiers. I see a single frameskip, but now I'm connected directly to the source stream.

The real purpose here is to relieve some of the pressure from the initial server. Maybe they've got 100/100, and I connect with my 20/5. Well, 5 isn't much compared to 100, but I'm pulling less than 1. Let's call it 1. Now the available bandwidth for streaming is 105 and I'm only using 1. With all them other folks connected up, the server might be only holding half the load. And higher bandwidths could get tiering priority, like, if I have 100/100, well, I get directly connected to the server pretty quick so I can redistribute the stream faster.

Oh, that's right, video comes in streams, not images... well, okay, it's got some problems. But it seems like a good solution to a very, very common problem. Make things easier on Hulu and Youtube (cause we all know they need the help, right?) and such too. Maybe drastically reduce the barrier for entry into that field, at least.

Just a thought.

Re:live stream

[FrostedWheat]

Which ironically uses Flash.

Re:live stream

[kipin]

http://torrentstream.org/

Works pretty well actually.

Re:live stream

[TooMuchToDo]

You've just described what multicast was designed to solve.

https://www.cisco.com/en/US/products/ps6552/products_ios_technology_home.html

Re:live stream

[suso]

I thought that was what multicast was for. Ouch! Too early.

Re:live stream

[game kid]

Doesn't multicast help any? Given a bunch of people who want to view the same exact stream, the server should be sending the same packets and letting the viewers' players deal with sync, starting at a key frame (and not in the middle of some crumbly diff frames), et cetera. With that, the server could just concentrate on the list of viewers' IPs, send packets far less often, and the /. arson fails.

Live streams, to me, seem easier than webpages because the viewer always wants the current frames of a live video but may want any portion of any other pages.

Re:live stream

[Mantis8]

Now all of us /.er's have a new past time...flash burning parties!

Re:live stream

[Rockoon]

..which ironically many feel should be destroyed.

Re:live stream

[SEWilco]

The webcam destroyer has only been running for 3 days so far. Keep an eye on it.

Re:live stream

[kirillian]

Someone already mentioned that this stream is broadcast with flash. There are actually some flash-based versions of multicast type technologies...I remember an octoshape(?) that was used to enable the broadcast of President Obama's swear-in over CNN if I remember correctly. There are also features built in to version 10+ of flash that basically make the above-mentioned structure possible. Needless to say, I will be happy to leave this coding house for a job where I don't have to code in the Flash world. Why did we ever as a society let marketing departments be in charge of ANYTHING??!!??!?

Re:live stream

[Anonymous Coward]

Just as a note, the difference between what you describe and bittorrent is that bittorrent is a swarm and you described a system with a structure with tiers. What you want is basically multicast and there are already some implementations of that.

The problem with bittorrent in particular is that bittorrent relies on each user obtaining a random part of the file and then share that and in return receive parts of the file that they do not have. With a stream you don't have that same sort of random start location. Instead every user just wants the newest bytes. So every user is either a leecher or a seeder at any one time.

It looks like some people have tried or are trying to make bittorrent a streaming system, but it does not seem inherently suited for the job.

Re:live stream

[Anonymous Coward]

I half expected to see a penis...

Re:live stream

[Jah-Wren Ryel]

Multicast doesn't help because no significant ISPs support multicast. You either tunnel it with something like MBONE - which is far beyond the ability of most users, or your routers have to be configured to participate. You might be able to do multicast between computers on a single ISP - depends on just what they have or have not done with their routers, but its only a handful of ISPs world-wide that support multicast over the internet.

Re:live stream

[owlstead]

What are you proposing? Gather enough slashdotters and watch in 3..2..1..go? Or do you have a special way to delay multicasts and predict the future?

Re:live stream

[RollingThunder]

And which works great for IPTV solutions. The end points subscribe to a channel by setting their IP, and then the upstream router decides if it needs to do the same, heading further back until it hits another router that's got the channel already subscribed.

Similar for when you leave the channel. Once the router decides it's not got any clients for a given channel, it'll unsubscribe from it and those will bubble back.

Very elegant, imo.

Re:live stream

[QuePasaCalabaza]

Octoshape has been around for a long time, sometimes colloquially referred to as octoshit. It tends to hog a lot of your upstream bandwidth. Adobe Stratus is going to be Adobe's offering in the P2P-assisted video streaming field as well.

Re:live stream

[adolf]

It is very nice. And it was around for a long, long time before people started using it for everyday television (IPTV). We used to call it the Mbone.

Re:live stream

[Anonymous Psychopath]

You've just described what multicast was designed to solve.

https://www.cisco.com/en/US/products/ps6552/products_ios_technology_home.html

Too bad it isn't enabled on the public Internet.

Re:live stream

[Anonymous Coward]

Not a problem anymore. Nobody reads slashdot anymo *poof*

Die?

[Denis Lemire]

You would think after the write cycles were exceeded the chips would be more or less read-only instead of 'dead.'

Am I mistaken on this presumption?

Re:Die?

[houstonbofh]

You would think after the write cycles were exceeded the chips would be more or less read-only instead of 'dead.'

Am I mistaken on this presumption?

Yep. When it dies, you can still write. It is just what you write won't be right. :) Hence the verify part of the test.

Re:Die?

[Entrope]

It depends on the architecture of the flash cells, but yes, I would expect that the chips would fail into some mode where erase and program operations have no effect. (Being a software guy rather than a Flash memory guy, I wouldn't want to guess whether over-erased cells would be at logic 1, logic 0 or a mix of the two.)

Re:Die?

[ledow]

Depends - if the chips are using some sort of error correction, they may well just fail. I have USB-based Flash die all the time and it DIES, as in not even presenting a usable device to the OS despite being "detected". The theory is that they fail nicely but the chances are that any non-premium flash will just die a death. Why bother making the device fail gracefully if it's failed anyway?

Literally - I've never seen a flash device in such a "read-only" mode, even for a single bit, but I can't even begin to count the number of flash-chips in certain devices (everything from routers to USB sticks) that just die for no reason and never recover.

Re:Die?

[Anonymous Coward]

What you're probably seeing is the microcontroller failing. The actual flash memory chips could be just fine but inaccessible.

Re:Die?

[fbjon]

It may be that the controller on the device just doesn't know what to do when something goes pear-shaped. To be sure, you should be accessing the raw NAND chip itself.

Re:Die?

[Chris Burke]

(Being a software guy rather than a Flash memory guy, I wouldn't want to guess whether over-erased cells would be at logic 1, logic 0 or a mix of the two.)

Well I'm not an expert on flash, but I know a little about how they work. In NOR flash the data line is pulled up to one, so that's the default state for any bit. There's a transistor connected to ground, and if the floating gate has a charge in it and the transistor is on, then it pulls the data line down to 0. "Erasing" a NOR flash sets all the bits to 1, and programming it sets certain bits to 0.

The most common failure mode as I understand it is that electrons get trapped in the floating gate even after erase cycles such that it's very close to or over Vt for the transistor, so that bit would be stuck in the "programmed" state of logic 0.

NAND memory is the opposite, the erased state is 0 and the programmed state is 1, so a permanently charged floating gate should result in a stuck-at-1 fault.

Which, relating to the OP's question, means either way the memory wouldn't be good for much of anything. Your NAND SSD is going to fail during an erase-program (aka "write") cycle, and except in the extremely unlikely case that the pattern you were writing did not involve changing any previously stored 1s to 0s on stuck bits, then the result is going to be wrong. You could read it, but you'd be reading the wrong data.

Re:Die?

[jnnnnn]

Your NAND SSD is going to fail during an erase-program (aka "write") cycle, and except in the extremely unlikely case that the pattern you were writing did not involve changing any previously stored 1s to 0s on stuck bits, then the result is going to be wrong. You could read it, but you'd be reading the wrong data.

I disagree. Flash memory erases whole blocks in one go (with a high-voltage pulse). It should be simple enough to check that the whole block got properly erased during the erase part of the write cycle. If not, that is a worn-out sector, and can be marked as such with no loss of data.

Getting stuck in the programmed state is a good thing, it makes the check easier (check for all zeroed before writing instead of checking for a correct write afterwards) and possibly faster.

Correcting some other inaccuracies I noticed during this discussion, flash memory is a specific type of EEPROM (electrically erasable programmable read-only memory). The main failure mode occurs because charge builds up in the gate oxide (the insulator between the floating gate and the substrate).

Re:Die?

[Chris Burke]

I disagree. Flash memory erases whole blocks in one go (with a high-voltage pulse). It should be simple enough to check that the whole block got properly erased during the erase part of the write cycle. If not, that is a worn-out sector, and can be marked as such with no loss of data.

Do flash drives actually do that? Read the block between erase and program cycles, I mean. I would have thought they would only read it once after the write is complete, if you were trying to detect bad blocks. As long as you didn't throw away the data buffer prior to checking if it worked, you wouldn't lose data either way. Wouldn't you have to know that the block wasn't all zeroes, or do another read prior to the erase?

The main failure mode occurs because charge builds up in the gate oxide (the insulator between the floating gate and the substrate).

Ah, the oxide, not the gate itself.

Re:Die?

[AdamHaun]

Your description is a bit backwards, at least for the NOR flash I work on. When the floating gate has charge (electrons), it turns the transistor off. The negative charge on the FG cancels out the positive voltage on the control gate. The bit is read via a current sense -- no current is a zero, lots of current is a one.

The main failure mechanism (that I know of) is oxide damage due to high energy electrons. Program and erase (technically, Fowler-Nordheim tunneling) take high voltages, which gives electrons enough energy to scatter into the oxide and get trapped. This repels other electrons. So what happens is that it takes longer and longer to program and erase until eventually you exceed the set limit, at which point it shows up as a fail. The bit will be in an indeterminate state. It may read correctly but won't have enough margin to guarantee data retention.

Re:Die?

[hitmark]

and sadly, thats a issue that can happen on any kind of media where the controller is integrated with the actual storage.

There seems to be more HDDs that go belly up thanks to logic board deaths then actual platter failure. And if the case is the same with SSDs or flash drives not handling a write error cleanly, we are in for a world of hurt, no matter what. At least with optical media or tapes, one can extract the actual storage part from the controller and try it somewhere else.

Subject here

[Anonymous Coward]

Flash! Aa-aaahhh!!

Re:Subject here

[Anonymous Coward]

He's a miracle!!!

Re:Subject here

[Chris Burke]

Now do that a million more times and we'll see if you wear out. Don't forget to include the live video feed.

Re:Subject here

[Rockoon]

King of the impossible!

Re:Subject here

[Anonymous Coward]

Flash, I love you, but we only have 14 hours to save the Earth!

Re:Subject here

[Yannic]

What's happening Flash?
[...]
But he can never fail

This really reminds me of why I shouldn't consume beverages while reading Slashdot. It was a near-miss.

Re:Subject here

[Anonymous Coward]

Flash! Aa-aaahhh!!

for the guy

[phantomfive]

For the guy a couple days back who asked what kind of project can he do that would be useful to the world, here is a great example. Try something like this.

Re:for the guy

[houstonbofh]

The fact that you said this shows you spend way to much time on slashdot. The fact that I recognized it, and was one of the first posters in the thread you refer to says the same about me. I wonder if I can find a life for sale on craigslist?

Link to thread in question...
http://ask.slashdot.org/story/10/05/23/1547202/Scientific-RampD-At-Home

Re:for the guy

[robot256]

Here, take mine, I don't need it anymore, apparently. I recognized the reference too.


Just kidding. I don't have one either.

Die Flash, DIE!

[Anonymous Coward]

Wait, which flash are we talking about here?

Re:Die Flash, DIE!

[hoggoth]

> Wait, which flash are we talking about here?

We're talking about flash photography, of course.

Re:Die Flash, DIE!

[Idiomatick]

http://www.rmog-guild.com/phpBB3/viewtopic.php?f=1&t=9738&start=0 ?

Re:Die Flash, DIE!

[Chris Mattern]

Wait, which flash are we talking about here?

The one that'll save every one of us, of course!

Re:Die Flash, DIE!

[bennomatic]

No no, it's German for "The Flash, THE!"

We need more of this

[Angst Badger]

Excellent work! Given that the chance that the manufacturers will provide this data approaches zero, this is the only way we're going to get realistic figures for the longevity of flash chips. Hopefully, this will encourage more independent hardware testing in other fields

Re:We need more of this

[hitmark]

the only issue is the funding of hardware that will be used until breakage, as it will be a direct expense to the tester.

dull

[Threni]

I was expecting something cool, like storing a picture, displaying it, and then constantly XORing each pixel with some random number twice, repeatedly, and watching the image decay over time. Although it would appear that it'd need quite a lot of time.

Ha!

[BJ_Covert_Action]

This project was inspired by the inevitable comments about flash longevity on every Slashdot SSD story.

Take that every 'dotter that says bitching on this website doesn't get anything done!

/removestonguefromcheek

Re:Ha!

[Bugamn]

• Teste SSD longevity: check
• Destroy evil Windows and Mac: in progress
• Create perfect government: who are we kidding?
• Get a girlfriend: better forget

Re:Ha!

[Anonymous Coward]

I don't know if I like being referred to as a 'dotter. I am male you insensitive clod!

SSD's? no.

[hypethetica]

article says: We used a Microchip 24AA01-I/P 128byte I2C EEPROM (IC2), rated for 1million write cycles.

Um, SSDs don't use anything like this part as their storage.

The more of you that watch, the faster it dies

[bluestar]

I bet the server's IP address is untraceable.

Re:The more of you that watch, the faster it dies

[Monkeedude1212]

Looking back on it, that was a pretty bad movie.

really old news?

[Anonymous Coward]

wasn't there a /. story about this several years ago? As in, someone who just wrote:

n=0
while true; do
head -c$(( 1024 * 256 )) > t.t
mount /mnt/usb
cp t.t /mnt/usb/t
umount /mnt/usb
mount /mnt/usb
cmp t.t /mnt/usb/t || { echo $n; exit 1; }
umount /mnt/usb
n=$(( $n + 1 ))
done

and ran it on an old computer for 5 years straight with no errors?

Relevant?

[Anonymous Coward]

He's running a test on one of the old EEPROM chips that have existed for maybe 30 years. This is totally different technology from the flash memory in modern devices (including memory cards, USB sticks, and solid state disks). This project really bears no relevance to solid state storage.

Re:Relevant?

[Anonymous Coward]

I wondered this myself, but I can't find anything on wiki that suggests EEPROM and flash aren't actually the same thing (floating gate transistors), besides the fact that flash is block-erasable whereas EEPROM is byte-eraseable.

Anyone out there know?

Re:SSD's? no.

[Kjella]

Yeah, that's what I was wondering too the moment I saw the 1 million cycles... what I heard was that SLC is usually rated for ~100k writes and MLC for ~10k writes, so completely different type of chip. So I'm not sure what this data will be relevant for, but it's not SSDs... what's this for, BIOS chips or something?

agreed

[thenewguy001]

but let's hope more than one third-party decides to run these tests so we have larger data sets and from separate sources.

Re:SSD's? no.

[ElectricTurtle]

I'd like to know what universe you get your SSDs from that don't use EEPROMs. Oh, you think the size is a big deal? Let me introduce you to a wild concept known as 'scaling'.

fake

[Anonymous Coward]

the numbers on the live video are updating at about 7 per second. even if the ssd was a 4GB one, that means 28GB/second. sorry i didn't know we already had SATA version 14 with supports 28GB second...

Re:fake

[egcagrac0]

They're writing and verifying a pattern to a 128 byte storage chip.

This is vaguely similar to what you might get without wear-leveling.

The display only goes to 9,999,999!

[Rick Richardson]

The display only goes to 9,999,999! I think that won't be enuf... should be 100M or 1G.

Re:The display only goes to 9,999,999!

[CannonballHead]

It will loop. They'll just have to keep count of how many times it looped...

Re:The display only goes to 9,999,999!

[Anonymous Coward]

Don't you mean 1B?

Re:The display only goes to 9,999,999!

[Silly Man]

But it will be *over nine thousand!!!*

Re:The display only goes to 9,999,999!

[Arthur Grumbine]

When I read his post I assumed he meant 1 Googol. Needless to say, I was awed by his optimism.

Re:The display only goes to 9,999,999!

[Ant P.]

The firmware is reprogrammable, the display can do up to 0xFFFFFFF.

256 million should be enough. If it isn't, then use the 7 segments to represent one bit each.

Re:The display only goes to 9,999,999!

[gparent]

No, he doesn't.

Re:The display only goes to 9,999,999!

[rsun]

He's got an unused decimal point on each digit. That says he can get to 1,279,999,999 (use the decimal points as a 7 bit binary number). That should be more than enough. I think the writeup even mentioned using them for something.

And it dies...

[Anonymous Coward]

NOW!

Myth Busters

[PSaltyDS]

Now, to see how much explosives it takes to MAKE it fail!

This is my favorite part! :-)

Re:Myth Busters

[confused one]

No no no. first they'll run it to the 1,000,000 write cycles. Then they'll to 10,000,000. Then they'll break out the home-made thermite.

Re:Myth Busters

[roman_mir]

No, the real question is 'Will It Blend?'

Huh?

[msauve]

If it fails on a write, then the data written is useless (because some random bit/s will be wrong), so the storage is "dead" in that it is no longer useful. IOW, it can no longer be used for its intended purpose.

"Read-only" refers to storage which contains useful information, in that it was written once with the desired data, even if it can't be again (ROM or PROM). So even though it's read-only, it still fulfills its intended purpose.

In any case, read-only = useful, dead = not useful; worn out flash = not useful.

Re:Huh?

[Denis Lemire]

Right, but failing gracefully into a "no more writes" state is far better than an "I'm dead and I took your data with me" scenario.

I honestly don't know which is more common or if it varies amongst various flash storage devices, hence why I raised the question.

People in general should but don't have backups of their data so this distinction is pretty important.

Re:Huh?

[msauve]

Since you don't know it's failed until you have an unsuccessful write, what "graceful" mechanism are you proposing?

Re:Huh?

[Denis Lemire]

Graceful as in data not related to your recent failed writes are still readable so they can be backed up and migrated to a new drive. Not sure why that concept is so difficult. I consider something dead as "completely unreadable, ALL your data has been destroyed - have a nice day."

No longer reliable but still semi recoverable isn't quite "dead."

Maybe I'm just using a stricter interpretation of the word dead than you are?

Let's use a marker on a white board analogy. If I was storing all my data on a suitably large white board using a marker and I completely exhausted my marker's supply of ink, I'd be pissed if this resulted in a blank whiteboard, wouldn't you? On that same note, if I wiped a small section of my whiteboard with the intent of writing something new in that area and only then realized that my marker was no longer suitably supplied with ink and my write failed, I would find the blank void in that section alone acceptable.

Does that clarify things?

Re:Huh?

[gumbi west]

(1) write data
(2) verify write worked
(3) if read worked, return to (1) as necessary
(4) else only allow reads.

Re:Huh?

[arkane1234]

The same kind of graceful mechanism that exist on SCSI or IDE harddisks, perhaps...

Re:Huh?

[msauve]

You left out

(2a) if write didn't work, fail

Re:Huh?

[gumbi west]

That is 3, maybe it should say

(3) if read read what write wrote... but that's a mouth full.

Re:Huh?

[Chris Burke]

Oh, yeah, I thought you were talking about reading data from blocks that had been written too many times. They're readable, but the data is likely to be garbage.

Other blocks would still be fine, probably both readable and writable.

The control logic for the memory will last as long as any CMOS circuitry, which is to say a pretty long time. Enough of the drive would have been rendered unusable to make you replace the whole thing before electron migration damaged control logic and prevented you from accessing the drive at all, most likely.

Re:Huh?

[hitmark]

also make sure that your not changing in place, but rather do copy-on-write, in essence writing the changes to a new sector rather then the one being changed.

Re:Huh?

[hitmark]

you can avoid some of that with copy-on-write, no?

that is, when changing existing data, you copy the data into ram, do the changes there, and then write the result to a new part of the media. Only after getting a successful read from that write do you then mark the old area as vacant, and the same with the ram used in the process.

Re:SSD's? no.

[Anonymous Coward]

Micron has SLC chips that do 1 million cycles as of 1.5 years ago.

Is this like

[jra]

That Castrol commercial with 50 engines running on engine stands with no oil in them?

Re:Is this like

[Anonymous Coward]

Its more like the one where the guy whips people with a dipstick.

Re:Is this like

[arkane1234]

Yep.. except this is real ;)

Re:Is this like

[h4rr4r]

The real test of that would be to take the engines apart after. I have seen something like that done and the engines run, but they are ruined and just waiting to die. It does not matter what brand of oil was in them before.

Re:SSD's? no.

[ElectricTurtle]

Oh bleh... AC box checked accidentally. The parent is me.

Re:SSD's? no.

[Yvan256]

You mean, like reptiles?

But how much data does it write?

[Edmund Blackadder]

Most modern flash memories have their controllers check which blocks are dying or dead and re-route write and read requests to good blocks. So while your flash may seem to be working perfectly well, various blocks inside it may be dying and its storage size may be progressively decreasing.

So I hope they are rewriting the entire flash in their test. Otherwise it is not representative.

Re:But how much data does it write?

[Rockoon]

Rewriting an entire SSD is time-prohibitive. It would take several minutes to write 32GB to the fastest 32GB SSD, now multiply that by the 10,000 write cycles claimed by the manufacturers... 20,000 minutes or so at a minimum... and thats without verifying the write.. so add in another 15,000 minutes or so...

In other words, it will probably take about a month to intentionally brute-force a full-bandwidth-kill of a 32GB SSD. Larger SSD's would take proportionally longer.

Re:But how much data does it write?

[fnj]

Nonsense, it's completely representative of normal use. That's exactly the point. Until data loss occurs, or there are no more free blocks to use, the flash memory is objectively perfectly good.

Re:But how much data does it write?

[blind biker]

They're testing an EEPROM: it is bit addressable and it does not contain any wear leveling algorithm.

Re:But how much data does it write?

[BikeHelmet]

It's also got vastly more write cycles available than MLC NAND.

Re:But how much data does it write?

[arkane1234]

A month is completely within tolerance... not for live video feed, but not beyond time sensitivity...

Re:But how much data does it write?

[Just Some Guy]

Most modern flash memories have their controllers check which blocks are dying or dead and re-route write and read requests to good blocks.

That's not visible to clients, though. If you buy a 32GB SSD, it doesn't gradually become a 31GB, then a 30GB, then a 29GB device as blocks wear out. I don't think there's a filesystem around that could handle that gracefully. Instead, it started as a 33GB SSD with 1GB reserved for bad block remapping, then decays to a 32GB drive, then starts pitching errors.

By the way, HDDs work exactly the same way. When the OS tells it to write a sector, only the drive knows where it actually gets stored.

(Actually, I lied about the first part: if you buy a 32GB SSD, you're getting 32,000,000,000 bytes +/- of storage. The spares probably account for the difference between 32GB and 32 billion bytes. (You can't make me say gibibytes. I am not Mushmouth and I'm not going to lip stutter for anyone.))

Re:But how much data does it write?

[Anonymous Coward]

A bit larger scale in some cases. My ioxtreme, for example, has 99GB of flash but only 80GB visible. So roughly 25% spares.

And it tells me the percentage of spares left.

Re:But how much data does it write?

[owlstead]

Hey, that's a bit too general. If I'm not mistaken my Intel G2 has quite a bit of redundant storage, and the Vertex drivers are using GiB instead of GB if I'm not mistaken.

Re:But how much data does it write?

[bynary]

If I'm not mistaken, platter-based hard drives do the same thing.

Re:But how much data does it write?

[blind biker]

Absolutely. It's like apples and hippos, as I wrote in another post :)

Re:SSD's? no.

[ElectricTurtle]

Actually, I rescind my post, as I realize I was confusing EEPROM with NOR/NAND. Your point is actually quite valid.

Re:SSD's? no.

[Anonymous Coward]

More importantly, the test pattern does not resemble normal SSD usage. Complete writes are very unusual for SSD and a cycle is not completed nearly as quickly as a cycle on this EEPROM (400 cycles per minute). When an SSD is written to in normal usage, a wear leveling algorithm distributes the data and avoids writing to the same physical blocks again and again. The German computer magazine C't has run continuous write tests with USB sticks and never managed to destroy even a single visible block on a stick that way. The first test (4 years ago) wrote the same block more than 16 million times before they gave up. The second test (2 years ago) wrote the full capacity over and over again. The 2GB stick did not show any signs of wear after more than 23TB written to it.

WRONG!

[Anonymous Coward]

This is internal EEPROM and is a whole different kettle of fish compared to the new state of the art sub-sub-micron stuff in flash drives now days.

The most important thing is that this is rated for an industrial environment. It's not going to prove anything!

Re:SSD's? no.

[robot256]

Okay, I'll bite. Let me introduce you to this thing called "functional equivalence". You do realize that even though they are all "nonvolatile storage," there is a difference between EEPROM and Flash, and that there are many different kinds of low- and high-density Flash and they all have different proprietary silicon designs with different characteristics?

Microchip EEPROMs are specifically designed for low-density, high-reliability applications, and are totally different at the transistor level from high-density MLC Flash used in solid state disks.

Re:SSD's? no.

[Anonymous Coward]

+1 Informative :)

I know

[billlava]

They could add an extra digit to the front of the display showing how many times the other numbers have reached their maximum! Brilliant, 10x the capacity for only one digit more!

Apples and hippos

[blind biker]

They're testing an EEPROM: while the underlining physics of storing data in an EEPROM and Flash RAM are the same - floating gate transistors - EEPROMs use best-of-breed implementations, single-bit addressable floating gate, while the Flash RAM found in SSDs is the cheapest, lest enduring MLC NAND. MLC NAND are the cheapest per bit, and have a write cycle endurance of two to three orders of magnitude lower than EEPROMs.

SSDs do not contain EEPROMs. They don't even contain SLC (NOR or NAND). In fact, SSDs don't even contain NOR MLCs. Only the cheapest will do, for SSDs.

Re:Apples and hippos

[Microlith]

They don't even contain SLC (NOR or NAND).

Some, usually the more expensive models, will use SLC NAND. No SSD uses NOR for data storage due to a total lack of density on that technology. They may for storing firmware/FPGA data, however.

Re:Apples and hippos

[owlstead]

Of course they do contain EEPROM. For the firmware :)

Re:Apples and hippos

[blind biker]

Which SSD contain SLC? Let's just say that I'm slightly skeptical about your claim.

Unless you mean those 4GB/8GB board-soldered memory modules that appeared in some of the ultraportables. By SSD I mean 3.5" form factor or such.

Re:Apples and hippos

[curunir]

Intel's Extreme line, for one. The X25-E goes up to 64GB. It's a 2.5" form factor, but it's a SATA drive and you can use a 3.5" bay with mounting rails to put it in a desktop.

GP is right about being expensive...expect to pay over $600 for the 64GB model.

Re:Apples and hippos

[somenickname]

All of these ones: http://www.newegg.com/Product/ProductList.aspx?Submit=ENE&N=2010150636%201749646482&name=SLC

"Flash Destroyer"?

[hey!]

Never heard of him. Is he a Marvel Universe character?

Re:"Flash Destroyer"?

[__aasqbs9791]

DC, duh! ;-)

Re:SSD's? no.

[tlhIngan]

Yeah, that's what I was wondering too the moment I saw the 1 million cycles... what I heard was that SLC is usually rated for ~100k writes and MLC for ~10k writes, so completely different type of chip. So I'm not sure what this data will be relevant for, but it's not SSDs... what's this for, BIOS chips or something?

Oddly, the NAND I deal with (MLC and SLC) tend to have ~1M writes for SLC, and at least 100k writes for MLC. The 10k flash chips I used were high capacity Intel Strataflash (MLC, but NOR), which aren't written as often.

NOR has markedly less endurance because it uses tunnelling one way (erase, I think) and hot electron injection the other way (write). Sending electrons blasting through insulation is a good way to wear it out. NAND flash uses tunnelling, so it doesn't wear as much.

I've also seen this kind of I2C flash with as low as 1k write/erase cycles.

And a little known fact is that these endurance ratings tend to be guaranteed by manufacturer. In practice, it's not unheard of to get 10x as many cycles in. The other thing is, flash gets slower as it wears out - if the cell doesn't die outright (i.e., insulation breakdown), the cell may take so long to program or erase that that internal programming/erasing timer expires and you get a timeout. That too is an error condition.

Re:SSD's? no.

[Wierdy1024]

Anyone feel like replicating this experiment with a standard flash chip scrounged from a USB stick?

It would also be nice to try an entirely software approach on a USB stick plugged into a pc, to see how good the wear levelling in commodity usb sticks is.

Re:SSD's? no.

[BobMcD]

Nah, fish.

The complete quote

[Locke2005]

Flash - Ah - Saviour of the universe
Flash - Ah - He'll save ev'ry one of us
Seemingly there is no reason for these
Extraordinary intergalactical upsets (ha ha ha)
What's happening Flash?
Only Dr Hans Zarkov formerly at N A S A
Has provided any explanation
Flash - Ah - He's a miracle
This mornings unprecedented solar eclipse
Is no cause for alarm
Flash - Ah - King of the impossible
He's for ev'ry one of us
Stand for ev'ry one of us
He'll save with a mighty hand
Ev'ry man ev'ry woman ev'ry child
With a mighty Flash
General Kaka Flash Gordon approaching
What do you mean Flash Gordon approaching?
Open fire all weapons
Dispatch war rocket Ajax to bring back his body

Flash - Ah
Gordon's alive
Flash - Ah - He'll save ev'ry one of us
Just a man with a man's courage
He knows nothing but a man
But he can never fail
No one but the pure in heart
May find the golden grail oh oh oh oh
Flash Flash I love you
But we only have fourteen hours to save the Earth

Flash!

Good luck

[Anonymous Coward]

what are the odds of multicast packets getting through all the routers on the internet...

Re:SSD's? no.

[Anonymous Coward]

I was about to joke with the moderating system, but mods shouldn't waste their points on this post. +-0 Agreeable.

I told you so.

[Jane Q. Public]

I am really not big on the "I told you so" thing, but in other stories about SSDs I mentioned that I could easily write a program like this, and some people called me an idiot and said I was full of BS. Well, to those specific people: See? Just maybe I knew what I was talking about after all.

Gloat gloat.

And now back to our regularly scheduled program.

Re:SSD's? no.

[mirix]

IIC EEPROMs are always too small for BIOS, I'm not sure what the biggest ones are, but they're quite small, maybe 2 or 4kB being the largest size.

They're generally used for menial stuff, For example... serial numbers on things, last operating mode (so battery powered devices can save states when power is removed), DIMMs all have them so that the machine knows what speed / config the RAM is (a PC's SMBUS is essentially I2C, there are slight differences but most things are identical and compatible).

The bus itself is rather slow, but can handle a whole bunch of devices, and only requires two wires.

BIOS is either stored on parallel bus (E)(E)PROM - The amount of E's depends on generation, OLD stuff was PROM (one time writable) or EPROM (rewritable, but requires UV to erase), starting around pentium era things went to EEPROM (electrically erasable). Modern boards seem to use SPI EEPROMs (this is also a serial bus like IIC, but dumber (no addressing) and it can be spooled up a lot faster). Some fairly recent boards still use parallel chips though.

Re:SSD's? no.

[mirix]

Is scaled up EEPROM kosher, then?

Re:SSD's? no.

[owlstead]

Moreover, since it costs money to evaluate the EEPROM for over 1 million write cycles, 1 million write cycles is what is commonly specified. That more or less means that it has been tested to do *at least* that. I would not be surprised at all that the actual number is substantially higher, even after testing multiple chips. I'm using smart cards that use 100K write cycles for their EEPROM but I was assured this was the verified lower bound. Since the lower bound is much lower on flash chips, it makes more sense to test them to the limit instead of just drawing a line at some power of 10.

It's not the worst case

[tepples]

The AC actually posited a worse case scenario, in that the whole disk was filled, and only one "spot" was repeatedly changed.

There are two ways to handle this:

• Reserve 5% to 7% of sectors to replace worn-out sectors. This conveniently happens to match the difference between 64 GB and 64 GiB. Some newer SSDs have "250 GB", which leaves over 9% of a 256 GiB module free for the controller to spread writes.
• Move this unchanging data from less worn sectors to more worn sectors to free up the less worn sectors for more rapidly changing data.

Re:SSD's? no.

[owlstead]

Yes, they do. They are basically testing how many times you can update the firmware. After 1.6M upgrades, it seems we'll have to worry.

I wonder...

[bynary]

...will the Flash Destroyer hold up under this load?

Why the gimick?

[Vellmont]

The counter sounds more like a gimmick than anything else. There also seems to be a dispute about whether the EEPROM they're testing is the same thing as a flash memory module. Real SSD and flash storage has wear leveling. Does this thing? Also, Flash memory comes in different variants (multi-level cell, single level cell, and likely other variations). Which is this?

So... I guess I have to wonder why not just some damn flash chips, and write a program to write to them over and over, then read. That sounds like about an hours work or so. It seems like they're more interested in creating a toy than actually producing independent relevant results.

Re:Why the gimick?

[SharpFang]

Wear leveling works only with partial fills.

If your flash has 1GB and 1000 write cycles, and your one write is 1MB, wear leveling will allow you to write your 1MB block 1,000,000 times instead of 1000 times. But if you wrote 1GB each time, it won't help you a bit.

In this case it seems the guy is writing the chip full of data so wear leveling won't make a difference (nor obscure the results.)

Re:SSD's? no.

[robot256]

Technically true, but I should have quoted Wikipedia:

Flash memory is a later form of EEPROM. In the industry, there is a convention to reserve the term EEPROM to byte-wise erasable memories compared to block-wise erasable flash memories.

I concede that there in principle Flash and EEPROM are very similar, but the fact remains that the Microchip part is made on a super-robust 180nm process, while state-of-the-art high-density flash chips use 60nm, 45nm or smaller transistors. There is basically no correlation between the longevity of the two processes because they are so different on the molecular scale.

Rename it "Flash Killer"

[drfreak]

1. Put a bunch of ad space on your web site.
2. Create a program called "Flash Killer" which has nothing to do with Adobe's software, but is still pretty cool, and put it on your web site
3. Post a story about it on slashdot.
4. Profit!

Re:Rename it "Flash Killer"

[SharpFang]

4. A bunch of nerds, all running Adblock raid your site.
5. Only marginal ad profit is gained.
6. Bandwidth bill arrives.
7. Loss!

3700 overwrite Cycles

[gweihir]

This is what I got from a 2GB Kingston Flash Key. After that there were errors in almost all overwrites. However the real kicker is that while the key read back wrong data, there never ever was any error reported. Since doing that beginning of 2009, I do not rust USB Flash anymore.

Set-up: Linux, 1MB random data replicated to fill the chip, then read back to compare. Repeat with new random data. I had one isolated faulty read-back around 3500 cycles and then from arounf 3700 cycles 90% (and pretty soon 100%) faulty read-backs. Language was Python, no errors for the device on STDERR, or the systemlogs. And I looked carefully.

About that longevity...

[Julz]

Haha. I was looking at the video and one of those ads popped up at the bottom of the video feed advertising "Top Anti-aging creams". Now I wonder? :P

FusionIO?

[Anonymous Coward]

Those IOdrives have been getting some flak over poor performance once the sucker has been filled once and the wear leveling is in play. I wonder if this could help prove the product is decent, or is in fact made of fail?

Re:SSD's? no.

[AdamHaun]

Tunneling is what does the damage (the electrons have more energy). I don't work on NAND flash but I suspect the greater endurance comes from having less margin for data retention. NOR flash is used in embedded applications, often under extreme conditions, and the data has to last for a long time.

This is a bad test

[AdamHaun]

I am working on flash write/erase cycling right now in my day job and I can tell you that this is not a very good test. Temperature affects cycling endurance (and this is reflected in the spec), so if your SSD is 20-30C higher than room temp it's going to make a difference. Fowler-Nordheim tunneling (which NAND flash uses for program and erase) is hardest at cold temperatures, so the first operation after powerup might be the worst case in a PC. (Yes, I know they're not using an SSD here, but they are doing their cycling at room temp.)

Another thing to keep in mind is that continuous cycling is not realistic. The wear-out mechanism here is charge trap-up, where electrons get stuck in the floating gate oxide and repel other electrons, slowing down program and erase. Over time, thermal energy lets the electrons detrap. So irregular usage in a hot PC should actually be nicer environment for endurance.

A final factor is process variation, which can only be covered by using a large sample size (>100) and/or using units from separate lots with known characteristics, none of which an end user will likely have access to. Even that doesn't tell you anything about the defect rate.

There are really two types of tests that people are talking about here. The first is a spec compliance test, which uses the extreme conditions I mentioned above to guarantee that all units will have the spec endurance under all spec conditions. This should be done by the manufacturer. The second is a real world usage test, which will only give realistic results if done under actual use conditions. The number you get from the article's test probably won't tell you much.

[Disclaimer: I work on embedded NOR flash, not NAND, but the bits are the same and the article's talking about EEPROM so I figure I can butt in.]

Airport Scanners

[Talahaski]

Pass through the airport scanners a few times and you'll see the drives start to fail