Page 6 of 220 FirstFirst ... 34567891656106 ... LastLast
Results 126 to 150 of 5495

Thread: SSD Write Endurance 25nm Vs 34nm

  1. #126
    Moderator Anvil's Avatar
    Join Date
    Apr 2008
    Location
    Norway
    Posts
    2,838
    Quote Originally Posted by One_Hertz View Post
    20.5TB. 90 wear indicator.
    Making progress
    Still the same avg. speed?

    Quote Originally Posted by Ao1 View Post
    One_Hertz, any chance of running perfmon to see how the 320 handles it?
    If you've got an HDD it would be interesting to see how that would look like.
    (I'll give it a try on my F3 as well)

    Media Wearout is either more correct on the SF or not working at all.

    The 90% Wearout on One_Hertzs 320 would lead to about 180TB of Host Writes.
    Still, with the MWI at 0 it can work for a long time, depending on whether there is sufficient spare-area left.
    -
    Hardware:

  2. #127
    Xtreme Mentor Ao1's Avatar
    Join Date
    Feb 2009
    Posts
    2,597
    As it happens I have a brand new F3. Here is the switch point between loop 2 & 3. Seemless.

    This is a freshly formated drive, but the speed seems quite fast for a HDD. (I'm using V3 of the SSD wrecker).
    Attached Images Attached Images
    Last edited by Ao1; 05-22-2011 at 09:47 AM.

  3. #128
    Moderator Anvil's Avatar
    Join Date
    Apr 2008
    Location
    Norway
    Posts
    2,838
    Here is mine, 7200 files deleted

    F3_Deleting_Files.PNG

    Doesn't look like anything happened during the deletes

    HDD-SSD : 1-0
    -
    Hardware:

  4. #129
    Xtreme Addict
    Join Date
    Jun 2006
    Posts
    1,798
    Quote Originally Posted by Anvil View Post
    I'll do some tests on the files using standard Zip or LZ like alfaunits suggested.
    Can you upload a sample somewhat large file for me? (128KB or more)

    Quote Originally Posted by Ao1 View Post
    0 fill option. So it seems that compressible data does not get throttled.
    0 fill on OCZ drives, IIRC, is equal to a TRIM. (or was it 0xFF?)
    IMO, 0-fill blocks would not get written to the SF drive at all, hence, there would be no NAND throttling from it, whether you write 500MB of 0-fill or 500GB of 0-fill.
    So, for your particular (endurance) testing, using data that is at all compressible for SF drives is probably masking the endurance results. (it will definitely not provide an idea of Host Writes minimum)

    Anvil, if you dedicate a separate thread for random generator, the CPU should be able to provide ample speed to write completely random data to the drive without any waiting in between (giving GC no time to react)
    Last edited by alfaunits; 05-22-2011 at 10:04 AM.
    P5E64_Evo/QX9650, 4x X25-E SSD - gimme speed..
    Quote Originally Posted by MR_SmartAss View Post
    Lately there has been a lot of BS(Dave_Graham where are you?)

  5. #130
    Xtreme Mentor Ao1's Avatar
    Join Date
    Feb 2009
    Posts
    2,597
    ^ The interesting thing however is that the impact of TRIM is the same. As soon as I started the test I noticed it and at that time it was writing compressible data. (See post 58) Even though the NAND was not written to it still took just as long to clean up.

    Below is what happens with my X25-M 160GB drive. It does not hang as the loop finishes, so TRIM implementations must be quite different between SF & Intel controllers.

    EDIT: And even my X25-M is getting whopped by an F3. LOL.
    Attached Images Attached Images
    Last edited by Ao1; 05-22-2011 at 10:21 AM.

  6. #131
    Uber Raid King Computurd's Avatar
    Join Date
    Aug 2009
    Location
    Wichita, Ks
    Posts
    3,887
    • Either the V2 has significantly better wear levelling or the SMART data is not as accurate.
    i think the vertex 2 wear indicator is ridiculously out of line. inaccurate smart data is my gut feeling. there is no way it is this bulletproof, they would market that to hell and gone if it were true.

    It must be a bit tricky for the SF controller to translate the OS TRIM command to the compressed data on the SSD.
    many have concluded that trim doesnt work at all with the SF, due to this very thing. is this the result of it not working???

    20.5TB. 90 wear indicator.
    WOW on track for 200 TB. and that is when IT thinks it will fail. my money says it last way longer

    EDIT: And even my X25-M is getting whopped by an F3. LOL.
    LOL for one microsecond the F3 beats an ssd !!
    "Lurking" Since 1977


    Jesus Saves, God Backs-Up
    *I come to the news section to ban people, not read complaints.*-[XC]Gomeler
    Don't believe Squish, his hardware does control him!

  7. #132
    Banned
    Join Date
    Jan 2010
    Location
    Las Vegas
    Posts
    936
    Quote Originally Posted by Anvil View Post
    I'll do some tests on the files using standard Zip or LZ like alfaunits suggested.
    I'm pretty sure the result is that it's being overdone already, I might even remove some of the steps from the loop.
    As long as you are testing it, I suggest concatenating a bunch of the smaller files into one larger file before compressing it. Just to prove that the data is not repeating on the file level (not that I doubt you

  8. #133
    Uber Raid King Computurd's Avatar
    Join Date
    Aug 2009
    Location
    Wichita, Ks
    Posts
    3,887
    using data that is at all compressible for SF drives is probably masking the endurance results. (it will definitely not provide an idea of Host Writes minimum
    big plus one here.

    great job btw guys, anvil especially! I know you guys are dedicating a lot of time to this, and it is very interesting!
    "Lurking" Since 1977


    Jesus Saves, God Backs-Up
    *I come to the news section to ban people, not read complaints.*-[XC]Gomeler
    Don't believe Squish, his hardware does control him!

  9. #134
    Xtreme Mentor Ao1's Avatar
    Join Date
    Feb 2009
    Posts
    2,597
    10TB - 100% life.

    the only change is:

    Delta between most-worn and least-worn Flash blocks: 3 (used to be 0)
    Attached Images Attached Images

  10. #135
    Moderator Anvil's Avatar
    Join Date
    Apr 2008
    Location
    Norway
    Posts
    2,838
    Quote Originally Posted by alfaunits View Post
    Can you upload a sample somewhat large file for me? (128KB or more)
    I'll do that later today.

    Quote Originally Posted by alfaunits View Post
    0 fill on OCZ drives, IIRC, is equal to a TRIM. (or was it 0xFF?)
    IMO, 0-fill blocks would not get written to the SF drive at all, hence, there would be no NAND throttling from it, whether you write 500MB of 0-fill or 500GB of 0-fill.
    That was the case using the Indilinx controller, not the SandForce.

    The SF controller handles 0-Fill or any other single value the same way, no doubt it would lead to exceptional "compression".

    Quote Originally Posted by alfaunits View Post
    Anvil, if you dedicate a separate thread for random generator, the CPU should be able to provide ample speed to write completely random data to the drive without any waiting in between (giving GC no time to react)
    Got too much on my plate right now but we might see such a thread

    Quote Originally Posted by johnw View Post
    As long as you are testing it, I suggest concatenating a bunch of the smaller files into one larger file before compressing it. Just to prove that the data is not repeating on the file level (not that I doubt you
    I've done a few tests using alternating 4MB buffers, will test that on the Areca later today.
    I tested the original model last night and
    100% incompressible data started at 1.5GB/s , it slowed down due to the array I was testing on, just a few drives but it shows the potential.

    100% incompressible data + no deduplication at the disk level
    was down to 330-350MB/s, so it does make a rather large impact.

    Both were tested on the 980X @ 4GHz.

    Quote Originally Posted by Computurd View Post
    big plus one here.

    great job btw guys, anvil especially! I know you guys are dedicating a lot of time to this, and it is very interesting!
    Thanks
    There is room for more drives in this test
    -
    Hardware:

  11. #136
    Xtreme Mentor Ao1's Avatar
    Join Date
    Feb 2009
    Posts
    2,597
    Quote Originally Posted by Computurd View Post
    LOL for one microsecond the F3 beats an ssd !!
    I've deployed the F3 now so I can't test further with it, however as the HDD can simply overwrite data without a performance penalty I would not expect performance to deteriorate in the same way as SSD, which incurs a read/ modify/ write penalty that is the unavoidable Achilles heel of SSD.

    Maybe the performance would drop as the HDD became fragmented, but with HDD I was getting 90MB/s. The X25-M was 67MB/s and the 40GB drives are coming in at 30 to 45MB/s.

    BTW, I noticed a TRIM "hang" in the middle of a loop. By the time I realised it was not at the beginning of a new loop I missed the opportunity to capture it

    I'll try to capture it I see it happen again, but it's a rare occurrence and I've only noticed it once.

  12. #137
    Moderator Anvil's Avatar
    Join Date
    Apr 2008
    Location
    Norway
    Posts
    2,838
    The "TRIM hang" in the middle of a loop could be anything from some system task disturbing the process or it might be the SF controller trying to do some housekeeping .
    I'll start saving some statistics for each loop in a database, should be handy for querying min/max values or just browsing.

    It would be particularly interesting to see the result with that drive w/o TRIM, well that would be interesting for all the drives I guess.

    If the wearout indicator doesn't move within a few more TB's (within this week) you might consider upgrading to the latest firmware, if that doesn't change I'd consider it a big bug.
    -
    Hardware:

  13. #138
    Xtreme Mentor Ao1's Avatar
    Join Date
    Feb 2009
    Posts
    2,597
    Bingo!

    When you turn TRIM off the hang disappears........but write speeds immediately drop.

    This is without even rebooting. As soon as you turn TRIM off the hang disappears and speeds drop.

    I'm a little worried about doing a fw upgrade. Things are running OK, so I don't want to mess anything up. Are there release notes for the new fw? Does it have TRIM enhancements?

    With TRIM you get a hang, without it speeds slow right down.
    Attached Images Attached Images
    Last edited by Ao1; 05-23-2011 at 04:39 AM.

  14. #139
    Moderator Anvil's Avatar
    Join Date
    Apr 2008
    Location
    Norway
    Posts
    2,838
    I'm not sure you should do that, it would possibly make a mess of the state of the SSD.
    It wouldn't change Host Writes in any other way than making an impact on throughput I'd guess.

    If you were to do so, I'd say you have to secure erase the drive when done testing w/o TRIM (from the toolbox).
    -
    Hardware:

  15. #140
    Xtreme Addict
    Join Date
    Jun 2006
    Posts
    1,798
    Quote Originally Posted by Anvil View Post
    That was the case using the Indilinx controller, not the SandForce.
    The SF controller handles 0-Fill or any other single value the same way, no doubt it would lead to exceptional "compression".
    An SSD surely has some bit fields that tell if a page/block is used/trimmed/erased. This bitfield would not take considerable space since pages are 4K.
    The above 3 states need 2 bits - but there is one state of the bits that is free for use. That state COULD be used to specify 0fill or 1fill.
    NAND would be spared the reads/writes, and speeds would be enormous.

    Since SF needs some bits to keep compression info and other data, I would guess they have lots of free bits for several states, so 0fill/1fill is extremely likely to not touch the NAND on SF drives at all.
    Would be nice if Tony would tell us something about this - pretty please with SSDs on top
    P5E64_Evo/QX9650, 4x X25-E SSD - gimme speed..
    Quote Originally Posted by MR_SmartAss View Post
    Lately there has been a lot of BS(Dave_Graham where are you?)

  16. #141
    Xtreme Mentor Ao1's Avatar
    Join Date
    Feb 2009
    Posts
    2,597
    Here I switch TRIM back on. Speeds remained lower until the TRIM command was executed by the SSD. Speeds then went back up.
    Attached Images Attached Images

  17. #142
    Xtreme Mentor Ao1's Avatar
    Join Date
    Feb 2009
    Posts
    2,597
    New f/w makes no difference. Now I will try a secure erase.
    Attached Images Attached Images

  18. #143
    Moderator Anvil's Avatar
    Join Date
    Apr 2008
    Location
    Norway
    Posts
    2,838
    Interesting Ao1

    I guess you are going to keep TRIM enabled

    Well, we now know for sure that it's TRIM that's causing the "pause".

    Don't know how much have changed, could be quite a lot, as long as 1.27 is working I'd keep it but if the MWI (Media Wearout Indicator) doesn't move within this week I'd consider taking some sort of action.

    edit:
    @alfaunits

    The SF drives are secure erased by sending a "specific" voltage to the NAND, it's described somewhere on OCZ forums.
    Last edited by Anvil; 05-23-2011 at 05:01 AM.
    -
    Hardware:

  19. #144
    Xtreme Mentor Ao1's Avatar
    Join Date
    Feb 2009
    Posts
    2,597
    1st loop on a secure erased drive with latest fw. Compressed data.
    Attached Images Attached Images

  20. #145
    Xtreme Mentor Ao1's Avatar
    Join Date
    Feb 2009
    Posts
    2,597
    1st loop 0fill. The impact of TRIM is the same regardless of the data format being written.
    Attached Images Attached Images

  21. #146
    Moderator Anvil's Avatar
    Join Date
    Apr 2008
    Location
    Norway
    Posts
    2,838
    Interesting indeed

    That shows that the drive was and still is operating at max speed while writing incompressible data, so, secure erasing didn't change a single thing in that matter.

    Doesn't look like it is going to get any better/worse performance wise, a great drive imho , it is outperforming the Intels on speed.
    -
    Hardware:

  22. #147
    Xtreme Mentor Ao1's Avatar
    Join Date
    Feb 2009
    Posts
    2,597
    I am surprised that the V2 is doing so well with regards to write speeds. Even when hammered it is faster than the Intel's. I really did not expect that.

    Can't say I'm too impressed with the way TRIM is implemented though. It effectively locks up the SSD and makes the app unresponsive.

    With raid you won't see locks ups because TRIM will not work, but on the other hand speeds will be impacted quite a bit without TRIM.

    I'm a bit surprised no one has picked this up before now. 5 seconds is a long time.
    Last edited by Ao1; 05-23-2011 at 05:51 AM.

  23. #148
    Moderator Anvil's Avatar
    Join Date
    Apr 2008
    Location
    Norway
    Posts
    2,838
    5 seconds is a long time no doubt about it, but, 10-15GB is also a lot to delete
    The pause was 1.5 seconds during my hIOmon testing of the VMs, so it's not like it's not a known "bug", it's even listed in the known issues part of the FW updates.

    So, would I prefer having 48MB/s but somewhat slow deletes or fast deletes and slower writes
    I'd like to see this "effect" on One_Hertz's 320 Series.
    Last edited by Anvil; 05-23-2011 at 06:43 AM.
    -
    Hardware:

  24. #149
    Xtreme Member
    Join Date
    Apr 2011
    Posts
    211
    Quote Originally Posted by Ao1 View Post
    I am surprised that the V2 is doing so well with regards to write speeds. Even when hammered it is faster than the Intel's. I really did not expect that.

    Can't say I'm too impressed with the way TRIM is implemented though. It effectively locks up the SSD and makes the app unresponsive.

    With raid you won't see locks ups because TRIM will not work, but on the other hand speeds will be impacted quite a bit without TRIM.

    I'm a bit surprised no one has picked this up before now. 5 seconds is a long time.
    Well done people ! This scientific research is already paying off. For science !

  25. #150
    Xtreme Mentor Ao1's Avatar
    Join Date
    Feb 2009
    Posts
    2,597
    Quote Originally Posted by Anvil View Post
    5 seconds is a long time no doubt about it, but, 10-15GB is also a lot to delete
    The pause was 1.5 seconds during my hIOmon testing of the VMs, so it's not like it's not a known "bug", it's even listed in the known issues part of the FW updates.

    So, would I prefer having 48MB/s but somewhat slow deletes or fast deletes and slower writes
    I'd like to see this "effect" on One_Hertz's 320 Series.
    If you were streaming video or audio files onto the SSD it would be a disaster if TRIM caused a lock up, even for a fraction of a second.

    Most people however would never notice unless you delete and then immediately start writing again.

Page 6 of 220 FirstFirst ... 34567891656106 ... LastLast

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •