SSD Write Endurance 25nm Vs 34nm

[Vapor]

You can do whatever you want with Win7 vs. XP

Just found it interesting that TRIM makes such an impact on WA (and it obviously has with speed, too).

I don't use NAND spec for calculating WA. I take SMART attribute C7 and divide by attribute D0 (and adjust units).

[Vapor]

SF-1200 nLTT Update

69.5TiB host writes, 42.78TiB NAND writes, 81 MWI, 684.5 raw wear (equiv), wear range delta 3, 56MiB/sec, MD5 OK

[SynbiosVyse]

9,968.87 GiB
42.58 hours
66.48 MB/s average

Stopping now and changing settings to:
46% Compression
MD5 checking enabled
Min GiB free to 1 (since I don't really want to add more static data)

I want to write a ton of data to this drive. The faster I can get it to LTT the better.

[bluestang]

You can do whatever you want with Win7 vs. XP

Just found it interesting that TRIM makes such an impact on WA (and it obviously has with speed, too).

Just broke 50 TiB mark

I think I'll let it run on Win7 over the weekend...gotta love the speed so far...

[Anvil]

That is a huge improvement bluestang

Why not keep it running off W7 24/7

--

232.58TB Host writes
Reallocated sectors : 6
MD5 OK

35.28MiB/s on avg (~22 hours)

[johnw]

398.182 TiB, 1079 hours, sa177: 1/1/32603, sa178: 64/64/366

406.012 TiB, 1100 hours, sa177: 1/1/33228, sa178: 62/62/380

Average speed reported by Anvil's app has been steady at about 113MB/s.

The other unknown SMART attribute 235 is still at 99/99/2, just as it was when the SSD was fresh out of the box.

64GB Samsung 470

Unless the decay in sa178 normalized accelerates, it looks like 30 to 60 days until it reaches 1. I wonder what happens at that point. Of course, I would not be surprised if the decay DOES accelerate, and there is less than 30 days left to reach 1.

[johnw]

Just remember that the WA calculation is our guess rather than a fact. WA of 5.14 would mean that the NAND on the Samsung is actually writing at 580MB/s which is rather doubtful.

I agree that we do not know for certain that the WA is 5.

However, I disagree that WA=5 implies that the Samsung is writing to flash at 580MB/s. I think it implies that the Samsung is erasing flash blocks at 580MB/s. Not exactly the same thing as writing data to flash at 580MB/s.

[Computurd]

what if it is doing them half and half? writing 290 MB/s and then erasing 290 MB/s?

[sergiu]

I would also agree that erasing must be done at 580MB/s. On the other hand, writing could be anywhere between 113MB and 580MB because it might need to rewrite some pages from the erased block. Because it can keep a constant speed of 112-113MB, I would say that internally is indeed writing much less than 580MB/s and it has not reached the theoretical max write speed.

[SynbiosVyse]

Corsair Force 40-A

14,567.35 GiB written
22.17 Hours
MD5 ok
58.79 MB/s

[Ao1]

Typical NAND specs:
Array performance
– Read page: 50μs (MAX)
– Program page: 900μs (TYP)
– Erase block: 3ms (TYP)

Hi SynbiosVyse
Could you post SMART attribute values for E9, F1, E6 & the MWI when you do updates? (The RAW 1byte value for E6 works as a count down to LTT.)

[SynbiosVyse]

Typical NAND specs:
Array performance
– Read page: 50μs (MAX)
– Program page: 900μs (TYP)
– Erase block: 3ms (TYP)

Hi SynbiosVyse
Could you post SMART attribute values for E9, F1, E6 & the MWI when you do updates? (The RAW 1byte value for E6 works as a count down to LTT.)

Like I said before I'm pretty sure most of the SMART info for Corsair's drives are borked. I started seeing stuff like this happening since firmware 2.0 (firmware 1.1 was okay). This screenshot was JUST taken (as you can see, barely anything has changed since my original, virgin screenshot several posts back):



Also notice the health is still at 100%, even after quite a bit has been written to the drive. Vapor believes it will go down eventually, but I will keep an eye on it. I would not be surprised if it is rigged to stay at 100%. I have worked a lot with these drives and with the older versions of firmware the health would drop pretty fast, ever since firmware 2.0 all drives I have seen are at 100%. Perhaps people have just not used them enough, we'll see.

[johnw]

406.012 TiB, 1100 hours, sa177: 1/1/33228, sa178: 62/62/380

415.193 TiB, 1125 hours, sa177: 1/1/33990, sa178: 60/60/398

Average speed reported by Anvil's app has been steady at about 113MB/s.

The other unknown SMART attribute 235 is still at 99/99/2, just as it was when the SSD was fresh out of the box.

64GB Samsung 470

[johnw]

Typical NAND specs:
Array performance
– Read page: 50μs (MAX)
– Program page: 900μs (TYP)
– Erase block: 3ms (TYP)

Typical block size 512KiB

8 channels x 512KiB / 3ms = 1.398e9 = 1398 MB/s

So it would only take 3 channels of block erase going in parallel to hit 525 MB/s of erasing. But it may be even faster than that, since I don't think the controller has to hold each channel until the block erase is done, so it can probably have more block-erases going on in parallel than there are channels.

[SynbiosVyse]

15.0575 TiB
26.29 Hours
58.79 MB/s
MD5 Ok

[Ao1]

E9 (if correct) is only showing 5,312 GiB of writes to NAND. F1, host writes, is showing 14,976 GiB. Were you running 0 fill? Now 46% fill?
LTT & MWI are based on E9. Increasing compressibility reduces the amount of writes that get recorded to E9.

[SynbiosVyse]

Yes that's correct. I didn't realize the raw values in hex had changed, strange that CrystalDiskInfo does not translate the hex to decimal? Why does it say 0 there?

[Ao1]

@ John
Those specs are for 25nm Mircon NAND, with a 1MiB block. I'd also guess multiple channels. Seems like the controller/ SATA interface add quite a bit of overhead. (Edit: easy to see why a clean drive can give really high benchmark figures)

@ SynbiosVyse
Function > advanced features > Raw Values > Select preference on how you want to see the values.

[bluestang]

M225->Vertex Turbo 64GB Update:

60.84 TiB
MWI 59 (drops by 1 for every 50 raw wear)
2064 Raw Wear
116.81 MB/s avg for the last 29.13 hours (on W7 x64)
MD5 OK

Man, this drive flys on Win 7

[johnw]

@ John
Those specs are for 25nm Mircon NAND, with a 1MiB block. I'd also guess multiple channels. Seems like the controller/ SATA interface add quite a bit of overhead. (Edit: easy to see why a clean drive can give really high benchmark figures)

So, double the erase speeds for a 1MiB block. The rest of that looks like a non sequitur. What are you talking about?

[Vapor]

bluestang, I'm tracking SMART attribute C7 (host writes in sectors), CF (average erase count), D0 (max erase count), D1 (MWI), and C3 (reallocation equiv, I think). If you could include those raw values (preferably in decimal) with each update, that'd be great. (also keeping tabs on speed and MD5 check, but that's not a SMART attribute, of course)

SynbiosVyse, I need the raw values (preferably in decimal) of SMART attributes E9 (NAND writes), F1 (host writes), B1 (wear range delta), and 05 (reallocation equiv, I think) from you, in addition to average speed, MD5 check, and E7 normalized value (MWI).

Doesn't matter if its a screenshot or written out, whatever is easiest for both of you

Also of note, your recent WA is down to just 1.22x (though I'm not certain about the numbers without the SMART attribute raw values). Before enabling TRIM, your WA was around 2.43x, so it seems TRIM has cut WA in half.

[Ao1]

So, double the erase speeds for a 1MiB block. The rest of that looks like a non sequitur. What are you talking about?

Those timings are at the NAND level. If a block is not clean, i.e. it contains a small of amount of valid data, that data has to be relocated before the block is erased, which adds time to the operation. Deciding where the data ends up is a processing task, which takes time to calculate. What I tried to say was that when a drive is in a fresh state it doesn't have to worry about any of that.

A secure erase can be executed in under ~ 2 seconds, so there must be a way to access and erase all blocks more or less simultaneously, so a block erase can be very fast if the controller does not have to be concerned about checking to see if data is valid, mapping data or managing WA.

When the drive is in a used state processing time is required, which adds overhead. As can be seen below that overhead can vary significantly depending on the state of the drive.

[johnw]

Those timings are at the NAND level. If a block is not clean, i.e. it contains a small of amount of valid data, that data has to be relocated before the block is erased, which adds time to the operation....

A secure erase can be executed in under ~ 2 seconds,...

In general it is true that GC may need to relocate some flash pages before a block can be erased. But in the specific case of ASU endurance test on the Samsung 470, I think that there is little relocation needed. For two reasons -- the amount of random writes are relatively small compared to sequential writes, and it is set to keep 12GiB free. With few random writes, 12GiB free, and TRIM, the GC just does not have much work to do.

As for SE in 2sec, I think that is highly dependent on the SSD. I've had a SE take more than 30sec (I think it was an Intel G1). And I've seen references to it taking a minute or two. Some SSDs have built-in encryption, so all it has to do is generate a new encryption key and mark all pages invalid in the index, so that could be done very quickly. But for SSDs without encryption, it is not "secure" to just mark all the pages as invalid -- it needs to go through and erase all the blocks. So I can see that taking more than a few seconds (but still less time than it would take to write zeros to the entire SSD).

[Ao1]

In principle I agree with you that an erase operation at the SSD level is likely to be significantly faster than host write speed capability.

Whilst I don't think the erase time is an issue for the WA calculation I'm still not sure how WA has been calculated. Somehow it does not seem possible that it can be so high, although the host write speeds imply that WA is being sacrificed to some degree.

It would be good if some of the key assumptions being made in the thread could be summarised in the first post.

It's interesting to see the difference TRIM has made to bluestang. Significantly faster write speeds and reduced WA.

[Anvil]

Regarding SE, did anyone monitor writes during an SE?

I've checked the SF drives and there are 0 writes, the 2 second SE on the SF based drives is due to that it is SE'd by sending a specific voltage to the NAND.

--

236.73TB Host writes
Reallocated sectors : 6
MD5 OK

33.34MiB/s on avg (~60 hours)