SSD Write Endurance 25nm Vs 34nm

[Anvil]

20.5TB. 90 wear indicator.

Making progress
Still the same avg. speed?

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.

[Ao1]

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).

[Anvil]

Here is mine, 7200 files deleted

F3_Deleting_Files.PNG

Doesn't look like anything happened during the deletes

HDD-SSD : 1-0

[alfaunits]

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)

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)

[Ao1]

^ 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.

[Computurd]

• 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 !!

[johnw]

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

[Computurd]

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!

[Ao1]

10TB - 100% life.

the only change is:

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

[Anvil]

Can you upload a sample somewhat large file for me? (128KB or more)

I'll do that later today.

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".

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

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.

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

[Ao1]

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.

[Anvil]

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.

[Ao1]

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.

[Anvil]

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).

[alfaunits]

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

[Ao1]

Here I switch TRIM back on. Speeds remained lower until the TRIM command was executed by the SSD. Speeds then went back up.

[Ao1]

New f/w makes no difference. Now I will try a secure erase.

[Anvil]

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.

[Ao1]

1st loop on a secure erased drive with latest fw. Compressed data.

[Ao1]

1st loop 0fill. The impact of TRIM is the same regardless of the data format being written.

[Anvil]

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.

[Ao1]

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.

[Anvil]

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.

[bulanula]

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 !

[Ao1]

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.