Slashdot Mirror

← Back to Stories (view on slashdot.org)

Micron Releases 16nm-Process SSDs With Dynamic Flash Programming

Posted by Soulskill on from the march-of-progress dept.

Lucas123 writes: Micron's newest client flash drive line, the M600, uses its first 16nm process technology and dynamic write acceleration firmware that allows the flash to be programmed as SLC or MLC instead of using overprovisioning or reserving a permanent pool of flash cache to accelerate writes. The ability to dynamically program the flash reduces power use and improves write performance as much as 2.8 times over models without the feature, according to Jon Tanguy, Micron's senior technical marketing engineer. The new lithography process technology also allowed Micron to reduce the price of the flash drive to 45 cents a gigabyte.

22 of 66 comments (clear)

  1. Lifetime at 16nm? by drdread66 · · Score: 4, Insightful

    Seems like the durability of flash cells decreases with every process shrink. It makes me wonder what the lifetime of this new stuff will be. A 10% reduction in cost is no bargain if it comes with a 10% reduction in lifetime.

    1. Re: Lifetime at 16nm? by drdread66 · · Score: 4, Informative

      I read it. It makes some claims that are not actually related to cell lifetime but rather to tricks they can play with the fancy firmware that allow them to do fewer writes and erases. That has nothing to do with the native cell lifetime.

    2. Re:Lifetime at 16nm? by angularbanjo · · Score: 2

      You must be new here.

    3. Re: Lifetime at 16nm? by viperidaenz · · Score: 3, Informative

      I don't understand how the native cell life is relevant.
      You're not buying flash chips from them, you're buying an SSD. The write endurance of the drive is what matters. How that is achieved is irrelevant.

    4. Re: Lifetime at 16nm? by AaronLS · · Score: 4, Interesting

      It may not have to do with cell lifetime, but it does relate to overall endurance. If their "tricks" are legitimate algorithmic approaches to improving endurance, then the native cell lifetime becomes less of a solid metric to endurance. It would be the analogy to when clock speeds of CPUs became less relevant when manufacturers began focusing on increasing pipeline throughput instead of clock speed.

      If a decrease from 20nm to 16nm feature size increases density by 25% and only decreases cell lifetime by 10%, then they will have more than enough new capacity to overprovision for the difference, and if their algorithmic improvements are legitimate, then that mitigates the need for additional over provisioning.

      There's alot of "if"s in there of course, because you can't always take such PR at face value.

    5. Re:Lifetime at 16nm? by Bengie · · Score: 4, Interesting

      Modern SSDs even move around data that isn't changing in order to keep an even wear. Assuming you're a normal user where most of your data doesn't change, then a 2x increase in storage with a 10% reduction in durability is a net gain. The issue of "wear" has technically already been solved for flash, but they have to figure out how to mass produce the changes. Flash is already getting replaced with mram soon. Several companies have system memory with mram slated within a few years, they've already retooled several plants.

      HP has gone one step further and is creating a dynamically allocated mram system that works as both system memory and data storage, so your harddrive and memory is all from the same pool. This reduces power usage dramatically and increases performance dramatically. At least in their own load test, they've gotten about an 8x reduction in datacenter power usage and almost a 2x increase in average workload throughput.

      They're currently working on custom Linux kernels that can dynamically allocate memory and storage instead of having to partition the pool between the two. A cool side effect is that "memory mapped files" are literally in memory all the time as storage is memory.

    6. Re: Lifetime at 16nm? by Kjella · · Score: 3, Informative

      Well, sometimes they make convenient little assumptions about the write amplification and other things in coming up with that number. Also it's the number they use for warranty claims, so it may not reflect the kind of endurance you'd normally expect. The latest trick is to basically use part of your drive as a semi-permanent SLC cache and only write it to MLC/TLC NAND later, if ever so what you actually get will depend on your usage pattern. If you just keep on rewriting a small file it'll probably not leave SLC at all, while if you use it as a scratch disk filling it up with large files and emptying it you'll hit the MLC/TLC hard. The rating is just to give consumers who don't want an in-depth look something to relate to.

      Personally my first idea was, if they can deliver us a MLC drive at 45 cents/GB doesn't that mean they should be able to deliver us a SLC drive at 90 cents/GB? That's not disturbingly much, considerably faster and should have all the endurance you'll ever need. That said, TechReport got 3 (out of 6) consumer drives they've written >1 PB to, so I'm guessing most drives fail from something else than NAND exhaustion. And I don't reinstall my OS disk every day.... I just checked and I've used up 50 of my 3000 P/E cycles after 150 days of 24x7 running so at this rate it should take 25 years.

      I know people who turn on their computer maybe 2-3 hours a day on average, just streaming no heavy media usage. Any SSD will last them forever, it's all about $/GB. Now if you want a guess they said 5000 P/E -> 3000 P/E (60%) for 25nm -> 20nm MLC, so I'm guessing 3000 * 0.6 = 1800 P/E for 16nm. And TLC is probably like 500 P/E, though this drive doesn't use that.

      --
      Live today, because you never know what tomorrow brings
    7. Re: Lifetime at 16nm? by viperidaenz · · Score: 2

      All of those questions are about the controller and it's wear levelling software, not the flash chips.
      In regards to your questions about security, the specific number of times a cell can be erased is irrelevant, only that wear level takes place and physical data is moved around to different locations and not immediately (or potentially, ever) erased from the old location.

      In theory, you should just need to delete the encryption key, because the controller encrypts all the data on the flash chips 256bit AES encryption. Again, that's entirely in the controller software.

    8. Re: Lifetime at 16nm? by Anonymous Coward · · Score: 2, Funny

      All you're base are belong to us!

    9. Re:Lifetime at 16nm? by Neil+Boekend · · Score: 2

      Any important data should be backed up.

      --
      Well, I might have a way, but it only works on a semi spherical planet in a vacuum.
  2. Mixed units by ArcadeMan · · Score: 2

    In other news, Nanon is expected to release 16m ICs soon.

    --
    Get free satoshi (Bitcoin) and Dogecoins
    1. Re:Mixed units by ArcadeMan · · Score: 5, Funny

      Stupid Slashdot can't even display UTF8 correctly. That was supposed to read "16um".

      Thanks for nothing, "nerds" website. We're in 2014, get with the damn program instead of fucking about with your stupid beta layout.

      --
      Get free satoshi (Bitcoin) and Dogecoins
    2. Re:Mixed units by gman003 · · Score: 2

      In completely unrelated news, Slashcode 14.08 has full UTF-8 functionality, and has been live on Soylent for almost a month now.

    3. Re:Mixed units by tlhIngan · · Score: 3, Informative

      Stupid Slashdot can't even display UTF8 correctly. That was supposed to read "16um".

      Thanks for nothing, "nerds" website. We're in 2014, get with the damn program instead of fucking about with your stupid beta layout.

      /. displays Unicode just fine. And it has for over a decade.

      The problem was back then people were abusing that functionality to screw with everything. If you google "site:slashdot.org erocS" that gives hints of what people were doing. If you don't get what that string is, try "5:erocS".

      As a result, /. implemented a Unicode whitelist because they keep adding all sorts of stuff to Unicode.

    4. Re:Mixed units by profplump · · Score: 3, Insightful

      It sounds like you're saying /. doesn't support Unicode. Make all the excuses you want about it being hard -- they might be true -- but Unicode support on /. does not exist. The idea that a whitelist (that doesn't even include mu) is evidence of support is like claiming that an F1 car is road-legal because you added headlights.

    5. Re:Mixed units by Kjella · · Score: 2

      Well, you must also know the HTML entities, even in plain text mode... writing æøå doesn't work, but æøå works. In this case µ doesn't work though. And I think all languages have Unicode support good enough to strip control characters and shit if you're not lazy. My impression was that it was more to sabotage the ASCII "art" than anything else.

      --
      Live today, because you never know what tomorrow brings
    6. Re:Mixed units by drinkypoo · · Score: 2

      As a result, /. implemented a Unicode whitelist because they keep adding all sorts of stuff to Unicode.

      Is there anything in this whitelist?

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  3. Confusion over TRIM by MobyDisk · · Score: 3, Interesting

    To deal with the added write amplification, Tanguy said Micron increased the TRIM command set, meaning blocks of data no longer required can be erased and freed up more often

    Did they mean "implemented" rather than "increased?" Or did they mean that they added something new to the TRIM command?

    1. Re:Confusion over TRIM by Firethorn · · Score: 2

      Well a 'command set' implies a set of functions, 1 command per function. So if you increase the command set, you've increased the number of functions, which means they added something new to the TRIM command.

      What that might be, I don't know. Going by his description, it sounds like they managed to implement some detection of non-allocated cells, which would allow them to re-allocate said cells without actually copying junk data to the new location.

      IE the system decides that block 105 is under-used and 657 is over-used. Normally this would involve copying what's in 657 to 105 and vice versa, but rather than blindly copy 105 to 657, it detects that block 105 isn't actually allocated(the file that was there has been deleted or something), so it just assigns the mapping from 105 to 657, saving a write.

      --
      I don't read AC A human right
  4. bc trim is application- dependant. Their assumptio by raymorris · · Score: 3, Insightful

    Making assumptions about how often trim might be used for any given workload only obscures the actual write endurance. Much like a 100GB capacity tape that's marked as 200GB because dome data that the manufacturer chose compressed 2:1 before being sent to the tape drive. Your mpeg movies aren't going to compress, so you'll be able to put 100GB of movies on that 100GB tape. The 200GB number is pure marketing BS.

    At least with tapes, all if the companies use the same 2:1 bs factor, so they can be compared. There's no telling what assumptions Micron made about the use of trim, so there's no way to compare this drive's endurance to any other, or to estimate it's actual endurance for any real workload.

  5. Re:bc trim is application- dependant. Their assump by LordLimecat · · Score: 3, Insightful

    Theres a lot of misconception here, so I'll try to address them.

    Making assumptions about how often trim might be used for any given workload only obscures the actual write endurance.

    TRIM has nothing to do with endurance. TRIM erases cells that are scheduled for erasure anyways; all TRIM does is try to time that erasure such that it occurs at a time that will not effect performance. What affects endurance is wear leveling, which is an entirely separate technique that does actually work. As capacity increases, wear-leveling ensures that the endurance of the drive as a total increases.

    Much like a 100GB capacity tape that's marked as 200GB because dome data that the manufacturer chose compressed 2:1 before being sent to the tape drive. Your mpeg movies aren't going to compress, so you'll be able to put 100GB of movies on that 100GB tape. The 200GB number is pure marketing BS.

    When tape manufacturers (or organizations, like the one behind LTO) cite a compression factor like 2:1, it is based on a standard body of data like the calgary corpus which includes both compressible and uncompressible data. This allows you to compare different technologies with different compression standards.

    In the real world on LTO (which I assume you are referring to) I have seen compression factors ranging from ~1.5 to 2.5, so its not really accurate to call it marketing BS. They also always (as far as I have seen) mark the tapes something like "800GB/1600GB" with the subtext explaining that the smaller number is native, and that the entire thing is 2:1. Its not dishonest because the compression is part of the (well-defined) standard, and the native capacity is right next to the compressed capacity. Its also not the manufacturer doing this; those numbers are explicitly defined in the spec.

    all if the companies use the same 2:1 bs factor,

    Which begins to make sense when you realize that thats because LTO itself defines the compression factor of 2:1 based on calgary corpus.

    There's no telling what assumptions Micron made about the use of trim

    But, as we've established, TRIM has literally no effect on endurance, so its irrelevant what they might assume about it.

    so there's no way to compare this drive's endurance to any other, or to estimate it's actual endurance for any real workload.

    Not to be harsh, but there is if you actually took the time to understand the tech. They usually do provide endurance stats (ie, "100PB data endurance") and tests by Anandtech and others have often validated that as being realistic.

  6. Re:bc trim is application- dependant. Their assump by goarilla · · Score: 2

    You mean ~1000 full rewrites. Hardware.info once tested this and got ~707 TiB until the first error (SMART: 5) out of a Samsung TLC 840 250 GB http://us.hardware.info/review....
    Anecdotal yes, but nice to know it was 3 x bigger than the manufacturers specs.