Analysis on OCZ Vertex E and 25nm process technology

Discussion in 'Memory and Storage' started by IntelUser2000, Feb 20, 2011.

  1. IntelUser2000

    IntelUser2000 Elite Member

    Oct 14, 2003
    Likes Received:
    There's a lot of talks that the 25nm chips used in the OCZ Vertex has only 3000 write cycles, and the performance loss is related to it. I have done some digging. Here's what I got.

    Review of the OCZ Vertex 60G E:

    Notice down the page the part number for the 34nm version: Hynix H27UBG8T2ATR

    Now the 25nm one: Micron 29F64G08CBAAA

    Another site has given their own opinion for the performance change:

    Strange thing. From the link above, it says Intel's NAND flash program/erase cycles are 5,000 cycles, exactly the same as the 34nm counterpart, and consistent with earlier claims the lifespan of 25nm chips = 34nm chips:

    Now the datasheet for the Hynix 34nm claims 3,000 write-erase cycles, which is significantly lower than the 25nm IMFT chip. If you look around though, you can see different NAND flash chips from different manufacturers have different write-erase cycles, even at the same process node.

    Intel 25nm specifications
    -5,000 program-erase cycles

    Read Performance
    -Random read latency: 50uS Max
    -Sequential read: 20ns(Min)

    Write Performance
    -Page program: 1200uS(Typ)
    -Block erase: 3ms(Typ)

    Hynix 34nm specifications:
    -3,000 program-erase cycles

    Read Performance
    -Random read: 200uS Max
    -Sequential read: 25ns(Min)

    Write Performance
    -Page program: 1600uS(Typ)
    -Block erase: 2.5ms(Typ)

    Not only the 25nm Intel chip has significantly better program-erase life, it has better performance specifications than the 34nm Hynix chip at nearly all matters, except Block erase.

    Except, OCZ Vertex 25nm isn't using Intel chips. In fact, no shipping SSDs use Intel's 25nm chips yet. Does it matter? I mean Intel and Micron uses the same fabs. Maybe it doesn't. Maybe it does and currently shipping ones and/or Micron's chips are the 3k lifecycle ones.

    It looks like the slow speed on the Vertex E is due to implementation. In fact, OCZ has a documentation saying the lower capacity(in this case, 60GB) has half the random write performance of the non E versions:

    The claimed 175MB/s read and 35MB/s write is consistent with measurements(like from CDM). The 60GB version of the E must be using 1/2 channel.
    #1 IntelUser2000, Feb 20, 2011
    Last edited: Feb 20, 2011
  2. Loading...

    Similar Threads - Analysis Vertex 25nm Forum Date
    Enterprise Optane SSD details leaked(plus analysis) Memory and Storage Feb 12, 2017
    Mirroring 2 OCZ Vertex 2 50gb as my boot drive? Memory and Storage Jul 28, 2016
    RAM performance test by frame time analysis [] Memory and Storage May 11, 2016
    A Cheap Controller of Interest, and a "Review Analysis" Memory and Storage Apr 12, 2014
    [XbitLabs] Analysis of Memory Frequency/Timing on IVB Memory and Storage Jul 9, 2012

  3. BogdanH

    BogdanH Member

    Feb 20, 2011
    Likes Received:

    Yes, it has been confirmed that's the case. And the same is true for Vertex2 120GB "E" version, which I've bought a week ago :'(

    The problem is, how manufacturers measure and declare performances. In case of my OCZ drive, there's label:
    Max Performance:
    Read: Up to 285MB/s
    Write: Up to 275MB/s
    The problem is, consumer doesn't know what "max performance" means -unless, one reads techie forums (like this). And "review" sites? Well, mixed bag... they somehow forget to tell what numbers are important in real usage.
    Ok, let me tell what "max performance" means this case: it means, user will get declared speed only if transferring files which are highly compressible (=contain uniform data, read: all zeroes or similar repeating content). Why? Because SandForce controller compresses files before writting. That is, when saving 100MB file, file gets compressed first, and result (say 60MB) is actually written -writting 60MB is faster than writting 100MB. Great idea!

    Reality is, we don't deal with such ideal data: jpg, avi, mp3,.. -they all are allready highly compressed (even native Word2010 doc files are actually zip files). Yes, we (users) are dealing with compressed files.
    And here, SandForce has a problem: i.e. compressed 100MB file can't be compressed anymore -hence, "real" 100MB must be written. And when this happens, users is confronted with "real" performance.
    Some of you would say "nobody would use SSD for avi, zip, jpg, mp3,... files". What for should we use SDD then? For OS pure? You decide.

    And then, the "famous" Vertex2, where OCZ decided (?) to reduce number of nand "power" of SandForce is clamped even more. I've made simple test by copying Win7 ISO file (3GB). And here's the result:
    1. Copying from HDD to SD : ~70MB/sec
    2. Copying from SDD to HD : ~100MB/sec
    And guess what: HDD is slow WD Green 5200rpm!

    About benchmark tools: some are saying ATTO is "customized" to show OCZ drives in better light. Not at all. One should choose right options: just use "I/O Comparison" option and select "Random" test pattern.

    Final words:
    What to say... SSD has impressive read performance, it's quiet, cold, silent.. in general, I can only highly recommend it: that's where you should have your OS on.
    As far OCZ concerns... I'll keep SSD I've bought (have no time for "fill complain", "send to", "wait from"). But probably I won't buy their products anymore.

    Thanks for reading,
  4. jimhsu

    jimhsu Senior member

    Mar 22, 2009
    Likes Received:
    As far as write cycles, I'm pretty sure that flash memory is graded based on estimated write cycles, and keeping in mind that these write cycles are just estimates. It is entirely possible that high-grade 25nm memory could have better write endurance than low-grade 34nm. The price, however, would probably also be higher.
  5. IntelUser2000

    IntelUser2000 Elite Member

    Oct 14, 2003
    Likes Received:
    The changes that happen moving to a new process isn't always straightforward. It might be true, that with a straight shrink, 25nm might have had much less write cycles than 34nm, or even the optimizations they added might have made it scale to 25nm. They'll obviously try to mitigate the problems weighed with cost.

    I do think there's a possibility IMFT was having problems with 25nm, hence the quarter or so delay. I also think they are working hard to meet 5k program-erase promised earlier this year.
  6. OS

    OS Lifer

    Oct 11, 1999
    Likes Received: