SSD Write Endurance 25nm Vs 34nm

[Anvil]

Well, we've started the quest to find out how long an SSD can last.

I'm using the Kingston SSDNow 40GB, a rebranded Intel X25-V and One_Hertz is using the new 320 Series 40GB SSD.

I'll be posting updates every day, well, thats my intention at least :)

This is the status of my SSD just before the test started.

114380

My SSD is currently running as the C drive on a laptop and it will continue to do that at least until it's up to 35TB, which is the expected life based on 20GB per day for 5 years.

So, 1/3 of the drive is filled with static data (W7 x64) an the rest is used for writes. The app fills the drive with random sized files ranging from 1KB up to 12MB in size.
More than 50% of the files are 128KB or smaller in size.
TRIM is active.

I'll be posting the first update within an hour or two, it's almost 24h since I started and thought that an 24hour update would be interesting.

Summary (in the works)

http://www.ssdaddict.com/ss/Endurance_participants_overview_1.PNG

http://www.ssdaddict.com/ss/Endurance_participants_overview_2.PNG

http://www.ssdaddict.com/ss/Endurance_participants_overview_3.png

http://www.ssdaddict.com/ss/Endurance_participants_overview_4.png

http://www.ssdaddict.com/ss/Endurance_participants_overview_5.png

16th of May, start of test
20th of May Ao1 entered the test with a Vertex 2 40GB using 34nm NAND
21st of May Ao1 produced a chart showing the SF "hang" during deletes (page 3) Link (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4855288&viewfull=1#post4855288)
21st of May, Vapor on compression Link (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4855837&viewfull=1#post4855837)
22nd of May, Ao1 summary/thoughts on the SF drive so far Link (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4856445&viewfull=1#post4856445)
22nd of May, Ao1 tries a Samsung F3 Link (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4856549&viewfull=1#post4856549)
23rd of May, overthere joins in and explains on Ao1's hIOmon testing Link (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4857353&viewfull=1#post4857353)
24th of May One_Hertz's 320 is at 26TB
24th of May Anvil's Kingston (X25-V) is at 22.5TB
24th of May One_Hertz's 320 got the first reallocated sector
26th of May, TRIM on Ao1's V2 is now up to 20 seconds. Link (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4861064&viewfull=1#post4861064)
27th of May Ao1 chart on compression/throttling Link (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4861199&viewfull=1#post4861199)
Link to white paper on impact of the frequency of writes. (recovery)
Read disturb
28th of May, Ao1's V2 started LT Throttling (7 days and 30TB), throughput is down to ~5MiB/s Link (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4862106&viewfull=1#post4862106) (page 10)
One_Hertz's 320 is at 43TB
Anvil's Kinston is at 35TB
30th of May, Kingston moved from Dell Latitute to AMD rig. (41TB, MWI 76)
We started using random writes "module"
2nd June, One_Hertz is at 60TB (MWI 70%)
Ao1 tries to revive the V2, it still throttles. Link (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4868027&viewfull=1#post4868027)
Discussion on how LTT is regulated, power on hours vs host writes
4th of June, Kingston is at 50TB MWI 71
Trendline for MWI exhaustion (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4869921&viewfull=1#post4869921)
7th of June One_Hertz's 320 78TB (MWI 60) which is 2x the advertised "endurance"
Ao1 ran the test for 6 hours, write speed 6MiB/s which equals about 500GB per day.
9th of June Ao1 summary and end of V2 test Link (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4876533&viewfull=1#post4876533)
11th of June
Kingston at 70TB, MWI 61
Intel 320 at 92TB MWI 53
13th of June Chart on MWI/Host writes Link (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4879418&viewfull=1#post4879418) (page 16)
15th of June
Kingston at 81TB MWI 55
Intel 320 at 107TB MWI 45
Discussion on Write amplification/wear leveling Link (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4881232&viewfull=1#post4881232)
16-17th of June, MD5 checking being implemented
Kingston is at 86TB MWI 52
Intel 320 is at 113TB MWI 41
Spec for Crucial 64GB drives is 72TBW (page 18)
21st of June, One_Hertz performed a full corruption test on his 320, no errors. Link (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4886280&viewfull=1#post4886280)
Discussion on testing, nand quality
22nd June
Kingston at 98TB MWI 46
Intel 320 at 131TB MWI 32
Chart by Ao1 on Host writes/MWI Link (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4887145&viewfull=1#post4887145)
Discussion on SLC, is it dead?
24-25th of June
Heated discussion on throttling :) which resulted in a new thread by Ao1
Intel 320 142TB MWI 27
Kingston 107TB MWI 41
"Up to 20GB Host writes per day for a minimum of 5 years" Link (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4889719&viewfull=1#post4889719) (page 22)
26th of June Chart by Ao1 Link (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4890727&viewfull=1#post4890727)
28th of June, Johnw enters the test with the Samsung 470 64GB SSD Link (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4892074&viewfull=1#post4892074) (page 23)
Discussion on Compression
29th of June Johnw's drive produces 12TiB in 24hours Link (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4892951&viewfull=1#post4892951)
Vapor and B.A.T announces they will be entering the test shortly
30th of June
Vapor on compression Link (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4893761&viewfull=1#post4893761) (page 25)
Pause after each loop is introduced.
Charts by Vapor (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4893893&viewfull=1#post4893893)
1st of July
B.A.T started testing the m4 Link (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4894416&viewfull=1#post4894416)
SMART table for Intel (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4894569&viewfull=1#post4894569)
SMART table for Micron (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4894595&viewfull=1#post4894595)
4th of July
Updated charts (page 29) (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4896931&viewfull=1#post4896931)
5th of July
The Samsung 470 sa177 attribute is already down to 1 (~63TiB) Link (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4897734&viewfull=1#post4897734)
Vapor received the C300 (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4897795&viewfull=1#post4897795) and has issues with SMART attributes, too many? (page 31)
6th of July
NAND info found by Ao1 (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4898579&viewfull=1#post4898579) (Intel 25nm, Micron 34nm, Samsung,
7th of July
MD5 testing introduced (page 32)
Updated charts, including C300 (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4899543&viewfull=1#post4899543)
8th of July
1st week of m4 summary (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4899875&viewfull=1#post4899875)
The Intel 320 is down to 3% (186.5TiB)
9th of July
Image by B.A.T of the NAND on the m4 (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4900590&viewfull=1#post4900590)
Listing of NAND by Ao1 (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4900679&viewfull=1#post4900679)
The Intel 320 is down to 1% (190TB)
Updated charts (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4901176&viewfull=1#post4901176) (page 34)
11th of July
The Samsung 470 is at 110TiB
13th of July
I'll be impressed if the Samsung 470 makes it past 200TiB (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4903883&viewfull=1#post4903883) says johnw (page 36)
Approximate Write Amplification chart added (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4903966&viewfull=1#post4903966)
15th of July
C300 is past 50TiB writes + updated charts (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4905350&viewfull=1#post4905350)
Some drama, My drive (X25-V) dropped out on the AMD rig (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4905567&viewfull=1#post4905567), moved to an Intel rig for further testing. (162TB)
m4 is past 100TiB
16th of July
Samsung 470 is past 150TiB (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4906144&viewfull=1#post4906144)
17th of July
My drive (X25-V) was off for the weekend, no issues.
The Intel 320 has 48GiB of flash (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4907310&viewfull=1#post4907310)
Intel 320 is at 217TiB, 24 Reallocated sectors.
Picture of the 320 (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4907500&viewfull=1#post4907500)
20th of July
Some info on normal usage (page 41 (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4909497&viewfull=1#post4909497))
21th of July
The Samsung 470 is past 200TiB avg speed 112MB/s (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4910331&viewfull=1#post4910331)
23rd of July
The X25-V is past 180TB host writes (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4911776&viewfull=1#post4911776) (reallocated sectors at 6)
24th of July
X25-V MWI is at 1
25th of July
C300 is past 100TiB (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4913381&viewfull=1#post4913381) + updated charts
nn_step on his Endurance testing (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4913525&viewfull=1#post4913525) (not part of this test)
26th of July
m4 entered Bad status state (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4913918&viewfull=1#post4913918) (MWI 10)
New chart by Vapor (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4914015&viewfull=1#post4914015)
27th of July
The app goes Beta (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4914328&viewfull=1#post4914328)
28th of July
m4 goes past 3000 P/E cycles (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4915477&viewfull=1#post4915477)
bluestang started testing the Crucial M225 (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4915516&viewfull=1#post4915516)
29th of July
m4 shows up as Good as attribute wraps around
Intel 320 is past 250TB, 33 reallocated sectors
bluestang needs to use Wiper on the Indilinx drive
Charts updated (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4916268&viewfull=1#post4916268)
30th of July
Vapor got an Vaporized (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4916598&viewfull=1#post4916598) SF-1200 drive w/o LTT
1st of August
BAT's m4 got past 200TiB Link (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4918309&viewfull=1#post4918309)
johnw's Samsung 470 got past 300TiB Link (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4918323&viewfull=1#post4918323)
4th of August
Charts updated (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4919999&viewfull=1#post4919999)
6th of August
A few bets are on? :) Link (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4921432&viewfull=1#post4921432)
8th of August
Vapor on Wear Range Delta on the SF-1200 Link (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4923015&viewfull=1#post4923015)
The Samsung is at 999 hours
10th of August
Ao1 on MWI on the V2 and the V3 he tested separately Link (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4924714&viewfull=1#post4924714)
Whitepaper on ECC (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4924765&viewfull=1#post4924765)
11th of August
SynbiosVyse entered the test with an Corsair Force 40A Link (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4924933&viewfull=1#post4924933)
Charts updated (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4924965&viewfull=1#post4924965)
B.A.T announced that he will be entering the test with an Kingston SSDNow V+ 100 64GB.
12th of August
The Samsung is about to go 400TiB (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4925723&viewfull=1#post4925723)
Adding TRIM to the formula changes WA for the M225, it also broke the 50TiB mark.
14th of August
The M225 really flyes on W7, MB/s almost doubled from XP
Chart posted by Ao1 on recycling (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4927306&viewfull=1#post4927306) (page 52)
P/E Interleaving/Channels/Dies (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4927806&viewfull=1#post4927806)
15th of August
Vapor's C300 is past 210TiB, Vaporized is at 85TiB
M225 is at 75TiB, Samsung 470 is at 433TiB, m4 64 is at 304TiB, F40A is at 25TiB
16th of August
Charts updated (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4928487&viewfull=1#post49
28487)
17th of August
Calculating WA for the Charts (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4929109&viewfull=1#post4929109)
M225's Erase failure count from 0 to 1 Link (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4929588&viewfull=1#post4929588)
Samsung 470 is showing signs of failure at 450TiB and is slowing down Link (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4929844&viewfull=1#post4929844)
19th of August
M225 past 100TiB, m4 is past 330TiB
20t of August
Samsung has less than a day left? at 472TiB (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4931669&viewfull=1#post4931669)
There is no LTT on the Corsair F40A (it is past 48TiB)
A bit of WA
21st of August
Samsung 470 is out of the test, 478TiB (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4932101&viewfull=1#post4932101)
Charts updated (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4932178&viewfull=1#post4932178)
The X25-V has finally reached 250TiB, it took >3 months.
22nd of August
B.A.T started testing the Kingston V+100 64GB (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4933489&viewfull=1#post4933489)
24th of August
Intel 320, the speed is increasing (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4935011&viewfull=1#post4935011) (339TB, 69 reallocations)
25th of August
m4 is at 375TiB, Kingston V+100 is at 17TiB, C300 is at 255TiB, nLTT = 123, X25-V = 260TB, Corsair F40A = 100TiB (0Fill)
29th of August
m4 is past 400TiB (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4938427&viewfull=1#post4938427) and the Kingston dropped out. (was quickly back up again)
Testing SSFLife
1st of September
C300 = 290TiB, nLTT = 126TiB, F40A = 126TiB, m4 = 424TiB, V100+ = 35TiB, X25-V = 280TB, M225 = 190TiB
(and I've ordred an F3 120GB)
2nd of September
Intel 320 40GB 370TB and 85 reallocated sectors. (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4941104&viewfull=1#post4941104)
4th of September
M225 reached MWI 0 (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4942760&viewfull=1#post4942760)
9th of September
X25-V gets past 300TB
Charts updated (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4945504&viewfull=1#post4945504)
10th of September
Development on the Intel 320 series, reallocated sectors from 105 to 4071 (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4946236&viewfull=1#post4946236) (could fail shortly)
Great post on P/E rating by frostedflakes (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4946481&viewfull=1#post4946481)
12th of September
Christopher is looking at candidates for testing...
m4 is at 511TiB (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4947971&viewfull=1#post4947971)
14th of September
jcool lists a X25-E with 580TB Host writes! (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4949375&viewfull=1#post4949375) Notice that MWI is still at 90
15th of September
m4 = 532TiB, C300 = 367TiB, nLTT = 226TiB,
17th of September
Ao1 lists endurance info from Intel Link (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4951875&viewfull=1#post4951875)
4K writes 100% span Intel Link (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4952061&viewfull=1#post4952061) (page 68)
The X25-V drops out on the AMD rig, works fine on the Intel rig?
4K Endurance? (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4952502&viewfull=1#post4952502)
19th of September
Loop write speed (bluestangs M225) Link (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4953204&viewfull=1#post4953204)
SSDLife predicts that the F3 120GB will last for 6 months 10 days (April 8th 2012)
20th of September
Corsair F40A = 190TiB, X25-V = 330TB
21st of September
F3 = 35TiB,X25-V = 333TB, both my drives are now running off an Z68 (ASRock) consuming 72W
22nd of September
The Mushkin Cronos Deluxe makes it's first appearance Link (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4955112&viewfull=1#post4955112)
23rd of September
Intel 320 = 438TB
SSLife now predicts that the F3 will last for 1 month 20 days.
C300 = 408TiB, nLTT = 263TiB w MWI stuck at 10 (proved to be normal) Link (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4956299&viewfull=1#post4956299)
24th of September
Christopher caught the SF2 bug Link (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4956420&viewfull=1#post4956420)
It happened to the F3 as well (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4956738&viewfull=1#post4956738) so both SF2 drives are affected by the bug. (mine lasted for 1 week)
25th of September
Christopher said about the Mushkin "I don't think this drive is going to die anytime this year (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4957297&viewfull=1#post4957297)" :) (famous last ...)
SynbiosVyse's F40A has gone past 206TiB
The F3 continues to disconnect
26th of September
The Mushkin disconnects
The F3 continues to disconnect
27th of September
Factory Bad Block count
SF2 discussions
B.A.T secure erased the Kingston after having issues.
28th of September
Charts updated (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4959614&viewfull=1#post4959614)
30th of September
m4 = 561TiB, Kingston V+100 = 81TiB, X25-V = 355TB, Force 3 = 101TiB, Mushkin Chronos Dlx = 72TiB, Corsair F40A = 229TiB
1st of October
C300 = 446TiB, nLTT = 296TiB
Workloads on Intel drives Link (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4961902&viewfull=1#post4961902) (page 77)
The Force 3 has been moved to another Z68 w/o results and is now running off an X58 ICH10R
The m4 gets past P/E 10000
2nd of October
command for smartmontools (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4962878&viewfull=1#post4962878)
1.3.2 fw released for the Corsair
3rd of October
The Force F40A died (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4963163&viewfull=1#post4963163)
The Force 3 lasted for 51hours on the X58 (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4963546&viewfull=1#post4963546) and then disconnected, it is not related to chipsets imo, updating firmware is next.
4th of October
johnw checked the Samsung on September 20 and it did not detect and managed to bend the connector, possible data retention failure!
One_Hertz will check the drive at his lab.
Jedec spec (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4964379&viewfull=1#post4964379)
1) The SSD maintains its capacity
2) The SSD maintains the required UBER for its application class
3) The SSD meets the required functional failure requirement (FFR) for its application class
4) The SSD retains data with power off for the required time for its application class
5th of October
The Force 3 disconnected again. (completely froze the system)
Reconfigured the computer to no C states (no power savings)
Voodoo Science :)
m4 = 604TiB, Kingston V+100 = 118TiB, Mushkin = 129TiB, (X25-V) 371TB, Force3 = 149TiB
6th of OCtober
Looks like C states combined with the new FW is what it takes to get it stable? (>46 hours without issues)
New thread created for the SF2XXX issues Link
(http://www.xtremesystems.org/forums/showthread.php?275704-SandForce-quot-SF-22XX-quot-issues-and-workarounds)
Wear Range Delta is a topic (page 82)
8th of October
Force 3 > 83 hours without issues
More on WRD (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4967694&viewfull=1#post4967694)
SynbiosVyse confirms that the F40A can't be detected (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4967846&viewfull=1#post4967846).
9th of October
The Kingston V+100 drops out again.
Link on Static wear Leveling (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4968569&viewfull=1#post4968569)
10th of October
The boot drive (Force 3 GT disconnected) so test had to be restarted
The Mushkin has been running for 45 hours w/o issues
WRD Charts by Ao1 (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4969490&viewfull=1#post4969490)
11th of October
One_Hertz gives his 320 another week or two (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4969766&viewfull=1#post4969766) :) (~488TB written)
12th of October
Reallocated sectors (4904) are still increasing on the 320 (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4970815&viewfull=1#post4970815)
13th of October
Windows issues a warning on the 320 (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4971301&viewfull=1#post4971301) as E8 is below threshold.
Charts on WRD/MWI by Ao1 (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4971672&viewfull=1#post4971672)
M225 Milestone, Erase count is past 1000 (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4972101&viewfull=1#post4972101)
14th of October
Intel 320 is at 499TB (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4972827&viewfull=1#post4972827)
Formulas linked by Ao1 (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4972931&viewfull=1#post4972931) (wear leveling/ P/E)
Force 3 uptime ~94 hours
15th of October
Intel 320 500.71 TB. 1 wear leveling reserve left! (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4973196&viewfull=1#post4973196)
Force 3 uptime 119 hours
The Intel 320 is still going strong!
16th of October
The Kingston V+100 dropped out again
Formula for calculating life-time (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4974085&viewfull=1#post4974085)
X25-V has 40GiB of flash. 40GB 320 has 48GiB of flash
17th of October
One_Hertz received the Samsung from johnw (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4975048&viewfull=1#post4975048)
The (X25-V) gets past 400TB
18th of October
No disconnects for over a week for the Force 3 (on fw 1.3.2)
(SF announces that the BUG is fixed?)
Chart on WRD/MWI by Ao1 (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4975668&viewfull=1#post4975668)
Speed is decreasing on the Intel 320 (down by ~3MB/s)
The m4 = 700TiB (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4975974&viewfull=1#post4975974)
19th of October
The Samsung 470 can't be revived (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4976270&viewfull=1#post4976270)
B.A.T announces that he will be entering 2 more drives
21st of October
(X25-V) 209TB, Force 3 271TiB, Muskin Chronos 207TiB, M224 Turbo 604TB, m4 724TiB, Kingston V+100(offline)
22nd of October
The Force 3 is idling to check if WRD changes, no changes were seen during 10 hours of idle time.
Intel 320 523TB 6977 Reallocated sectors
23rd of October
F3 refreshed the drive by moving all data off the drive and then back again. Link (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4979295&viewfull=1#post4979295)
WRD started decreasing when the test was restarted.
24th of October
B.A.T startes testing the Intel X25-M G1 80GB (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4980360&viewfull=1#post4980360)
B.A.T's MTron SLC fails do co-operate and won't be joining the test (for now).
25th of October
One_Hertz initiates a retention test on the Intel 320 (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4980679&viewfull=1#post4980679)
The m4 gets past 750TiB
27th of October
The X25-M G1 is slowing down and needs attention to perform.
* Uploading images is no longer supported on the forum??
28th of October
X25-V 431TB, Force 3 336TiB, M225 662TB,
31st of October
The Mushkin has had 128 hours uptime,
The test-rig (Z68) for the Force 3 has been up for 12 days, the F3 has worked for 179 hours
1st of November
M225 is past 701TB (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4985542&viewfull=1#post4985542)
2nd of November
bluestangs logfile (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4986426&viewfull=1#post4986426)
3rd of November
X25-V 446TB, Force 3 383TiB (uptime > 251 hours), Mushkin Chronos 404TiB (uptime 207 hours), M225 722TB,
4th of November
Charts by Ao1 (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4987715&viewfull=1#post4987715)
The Mushkin has been running for 240 hours, the Force 3 for > 275 hours.
The Mushkin has started generating a few more retired blocks
5th
JEDEC states (on Endurance) (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4988135&viewfull=1#post4988135)
The Intel 320 is back (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4988415&viewfull=1#post4988415), no issues. (offline since October 25th)
6th
The Mushkin starts having issues (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4988876&viewfull=1#post4988876) (at 432TiB)
B.A.T is back with a new born (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4989208&viewfull=1#post4989208)
Unfortunately the m4 is bricked, it was disconnected for 9 days and it did not survive, data retention is to blame.
7th of November
The thread has had more than 500.000 views (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4990125&viewfull=1#post4990125) :)
The Samsung 830 carries a SMART attribute for host writes (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4990141&viewfull=1#post4990141)
8th of November
M225 gets past 700TiB (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4990733&viewfull=1#post4990733)
Kingston V+100 gets past 200TiB, Intel X25-M ~25TiB,
Link to JEDEC (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4990919&viewfull=1#post4990919)
9th of November
Christopher discovers that RRER is below threshold on the Mushkin and this is the cause of CDI is reporting errors (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4990989&viewfull=1#post4990989) (465TiB)
The Corsair Force 3 is at MWI 10 (which is really 0) at ~438TiB
10th of November
The Mushkin died (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4992034&viewfull=1#post4992034) at 475+TiB
M225 794TB, X25-V 466TB, Force 3 447TiB, Kingston V+100 215TiB, X25-M G1 33.5TiB,
11th
Small summary by sergiu (on causes of death) (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4992472&viewfull=1#post4992472)
M225 is past 800TB
13th of November
The Kingston V+100 still disconnects, frequently.
Christopher shows signs of re-entering the test with some drive :)
The Force 3 is about to overtake the X25-V (which has been running for almost 6 months)
15th of November
B.A.T orders another m4 (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4995117&viewfull=1#post4995117) :)
The M225 overtakes the m4 on TiB Host writes (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4995643&viewfull=1#post4995643) (768.91TiB)
17th of November
Intel 311, just a teaser (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4996805&viewfull=1#post4996805)
Quick retention test on the Force 3 and the X25-V
18th of November
Completed retention testing both drives for 11 + 24 hours, all is well.
Recovery between P/E cycles (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4998073&viewfull=1#post4998073) (linked by Ao1)
M225 gets past 800TiB (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4998112&viewfull=1#post4998112)
The Force 3 gets past 500TiB
19th of November
Intel 320 -> 573.3TB. 7424 reallocated sectors (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4998514&viewfull=1#post4998514) (page 109)
Kingston V+100 263TiB, X25-M G1 68TiB
The Kinstson has issues and has slowed down to 1/3 of it's original speed, < 30MiB/s
21st of November
The M225 is reported dead (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4999749&viewfull=1#post4999749)? it is later revived (823TiB, 905TB total)
It *fails* the MD5 test later that day. (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=4999810&viewfull=1#post4999810)
bluestang had a power outage, it still works (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=5000614&viewfull=1#post5000614)
25th of November
The X25-V gets past 500TB (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=5002516&viewfull=1#post5002516)
30th of November
Intel 320 604TB, Force 3 604TiB, X25-V 515TiB, M225 846TiB, X25-M G1 80TiB
(The Force 3 is having another retention test today)
1st of December
Christopher announces that he will be entering with an Samsung 830 64GB (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=5006721&viewfull=1#post5006721)
2nd of December
The Force 3 survived the 54 hour retention test. (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=5007504&viewfull=1#post5007504)
5th of December
The battle of the... is about to start (Samsung 830 + Crucial m4)
The M225 has issues having idled the weekend (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=5009266&viewfull=1#post5009266)
6th
M225 struggles again and it's close to 1PB
First update on the Samsung 830 (http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm&p=5009266&viewfull=1#post5009266) and the new m4 64GB
M225 876.17 TiB (963.36 TB) total, bluestang will babysit the little drive :)

(page 116/117)

....




Updated charts :)


Host Writes So Far

http://www.xtremesystems.org/forums/attachment.php?attachmentid=120583

http://www.xtremesystems.org/forums/attachment.php?attachmentid=120584


Normalized Writes So Far
The SSDs are not all the same size, these charts normalize for available NAND capacity.

http://www.xtremesystems.org/forums/attachment.php?attachmentid=120585

http://www.xtremesystems.org/forums/attachment.php?attachmentid=120586


Write Days So Far
Not all SSDs write at the same speed, these charts factor out write speeds and look at endurance as a function of time.

http://www.xtremesystems.org/forums/attachment.php?attachmentid=120587

http://www.xtremesystems.org/forums/attachment.php?attachmentid=120588


Host Writes vs. NAND Writes and Write Amplication
Based on reported or calculated NAND cycles from wear SMART values divided by total writes.

http://www.xtremesystems.org/forums/attachment.php?attachmentid=120589

http://www.xtremesystems.org/forums/attachment.php?attachmentid=120590

http://www.xtremesystems.org/forums/attachment.php?attachmentid=120591

--

http://www.ssdaddict.com/ss/Endurance_failed_drives_mwi_tib.png

http://www.ssdaddict.com/ss/Endurance_failed_drives.png

http://www.ssdaddict.com/ss/Endurance/Endurance_cr_latest.png

[lowfat]

So the entire drive is being used, so no extra space for wear leveling? Either way, very interested in results.

[One_Hertz]

There is always at least 12GB of empty space. My conditions are very similar except that I don't have my windows running on the drive (I did place 11GB of static data on it to compensate). I am having some difficulties with the PC I am using for this crapping out so I am not going 24/7. Maybe 18h a day due to BSODs. I am only at 1.5TB so far.

[Anvil]

24 hours

This is the application thats running the show, a bit of info for the current session
114391

Looks like my setup produces 2.7-2.8TB per day.

CDI shows that E9 Wear-out has gone from 99 to 97 in 24 hours, lets see how that attribute develops the first few days/weeks.
Nothing else has changed.

114390

[Computurd]

very interesting! cant wait to see how this pans out...

[Ao1]

So worst case of 4K 100% random, full span = 5TB
20GB a day normal use x 5 years = 35TB
2.8TB a day/ 35TB = 12.5 days

This is going to be interesting :)

Is the drive slowing down a lot?

Anvil is that app something you made? :cool: Is it going to be the platform for the benchmark tool as well?

@ One_Hertz, does your drive have TRIM?

[CedricFP]

Very eager to see the results of this!

[Anvil]

@Ao1

Yeah, it's the app I've been developing, it started out as a small utility for importing iometer result files and now it includes a storage benchmark and a lot of WMI stuff, I've been adding some SMART stuff as well but that part isnt ready yet.

A download link is coming your way soon :)
(maybe this week)

It doesn't look like it's slowing down, we'll see later tonight, will be posting an update at about 5TB Host Writes.
(there has been some development on the SMART attributes, nothing alarming though)

[One_Hertz]

@ One_Hertz, does your drive have TRIM?

Yep it is in a W7 machine with TRIM. I am at 3.2TB now and my wear indicator just changed to 99. My drive is not slowing down.

[Anvil]

How are things running?

I'm past 5TB Host Writes, will post an update soon.

I've been checking a few things wrt SMART attributes on the Kingston vs the X25-V and they are identical as to what attributes are reported.
There was a question at the Intel forum about attributes E2-E4 on the Kingston V40 as it was showing 0xFFFF (65536) on my drive and apparently there was an issue with the log, I ran smartmontools and it looks like it cleared the condition.

Anyways, those attributes are not reported by any of the Intel SSD Toolboxes and afaikc they don't mean squat on the old series (as in not being documented), I even updated from 02HD to 02M3 on one of my Intel X25-V's and it didn't change a thing,

Smartmontools r3317 disagrees with earlier versions and is reporting
E2 (226) as : Workld_Media_Wear_Indic
E3 (227) as : Workld_Host_Reads_Perc
E4 (228) as : Workload_Minutes

I'll check whether those values makes sense on the Kingston, the Kingston will need to stay at 02HD though :)

[Anvil]

Time for an update.

I stopped the process for 2 minutes just to check if it would mean better performance *if* I added a small pause everytime files were deleted, it didn't and so no changes will be done in this regard.

114411

47 hours and a few minutes.

114413

So, ~5.2TB in 47 hours.
Re-Allocated sectors have increased from last time from 1 to 2
E9 Media Wear-out has changed from 97 to 96

E2-E4 are now showing "something" but what :)

114412

I'll check out the latest "smartmontools" and I might give it a try if there are "issues" with CDI.
Intel SSD Toolbox is probably the better option.

[One_Hertz]

I've caught up to you in writes but my wear indicator is at 98 with all other parameters not having any changes. I guess I don't feel as if there is anything interesting going on yet. Probably nothing interesting will happen at the very least until 30-40TB mark. I do not expect it to last past 100TB, but we will see.

p.s. I'm using the latest Intel Toolbox to read SMART parameters.

[mbreslin]

My guess is even a lowly x25-v will not substantially slow down until 3 times as much as the usual 20gb/day number. 100+ TB before substantial slowdown.

[Ao1]

So roughly 1.3TB per 1% wear out for the X25-V= 130TB.

Quite impressive that it is writing 2,867GB a day without significant slow down. (Especially considering the write workload).

[Metroid]

I do not expect it to last past 100TB, but we will see.


Interesting, some hours of considerations made you to change your mind to no way to maybe. The way things are going even 150TB is believable.


So roughly 1.3TB per 1% wear out for the X25-V= 130TB.

Quite impressive that it is writing 2,867GB a day without significant slow down. (Especially considering the write workload).

Mine got 1.65TB per wear, 16GB free space.

I will place my drive too in the coming months. That may give a different outcome.

[Ao1]

Its incredible really. A 40GB drive is writing 71 times its capacity a day. The 320 has less PE, but can cache writes to offset wear. So far it looks like half the wear on the 320 compared to the X25-V for the same amount of writes.

What will be really interesting is how much more the drive can write when the wear out indicator gets to 1. I suspect the wear out indicator is based on an arbitrary PE value as opposed to the actual PE capability of the NAND. Should soon see though. :up:

Someone should try this on an SF drive to see what happens. Anvil are the randomly generated files compressible?

[Anvil]

The files are compressible, they are filled with "garbage" but that's not a problem, I've already done whats needed for selecting compression level for the SF controller.

So far one can select
- 0-Fill
- 8% (Databases are normally in this area)
- 25%
- 46% (Apps, dll's,...)
-100% (Incompressible)

I did actually look at todays offerings and found the 60GB SF on special offer at $140 which is extremely cheap considering the prices in Norway.
I'm just wondering whether I'm up for it or not, it does require a bit of attention and the SF drives would require a lot of work compared to other drives that don't throttle.

It would be interesting to know how fast one would reach full throttle and if full throttle is bearable.

[thebanik]

hmmm...would be very interesting to see the results....Nice work...

[Ao1]

I can pick up a V2 40GB drive really cheap. I'm hesitant however. If throttling kicks in it will take forever so I don;t want to do it on my main pc. I'll scrat around and see if I can build a pc from spare parts.

[Anvil]

That would be really great :)

And No, you don't want this thing running off your main computer, even though the computer is still *very* responsive it's just to much of a hassle.

I expect the 40GB would be on par with the X25-V initially (depending on compression level), a mix of all levels would be preferable and is not a problem.

[[XC] Oj101]

Subscribed. I'd like to see if you really will kill it in two weeks :eek:

[zalbard]

So 5TB roughly = 4%...
I'd say the drive should perform well enough even after 50TB in this case. And the death would occur after 125TB. At least according to the current results. So much for 15TB endurance claims... We'll see, though.

Edit: the wear speed should accelerate due to dying cells and thus, spare area getting smaller over time, though.

[Ao1]

Ok, I've ordered a 40GB Vertex 2E, whatever that is. I'd guess 25nm, but will take it apart before I start to find out for sure. Should have it tomorrow.

Anvil, can I use your tool with the exact same config you and one_hertz are using?

If write speeds end up being ridiculously slow I may abort.

[Anvil]

Ao1

Sure, I'll e-mail you later today.

This is going to be really great, at least we will find out a bit more about throttling.

[One_Hertz]

Interesting, some hours of considerations made you to change your mind to no way to maybe. The way things are going even 150TB is believable.

"No way" was in regards to 1PB, or 1000TB. 100TB was always a maybe :)

I am at 6.X TB with 97 wearout indicator. So far the 320 I have is doing 2gb+ per point of the wearout indicator value.

Ao1 - I highly doubt the sandforce controller will let you do this... It will just slow down to the point where the drive is not usable. Does secure erase reset things on these controllers?

[Anvil]

Yes, Secure Erasing looks to stop the throttling, however, it's not what one wants, especially for a system/boot drive.

There may be restrictions along that path though, my drives aren't that much used for benchmarking so I just don't know, it's been working the few times I've felt I had to clean them.

[Micutzu]

Interesting, some hours of considerations made you to change your mind to no way to maybe. The way things are going even 150TB is believable.

...

Flash cell wearing might not be - and probably isn't - linear with the amount of data written on the drive. From a certain point, the wear indicator will start to accelerate.

[Ao1]

You mean the paranoia cliff in this slide (http://www.xtremesystems.org/forums/showpost.php?p=4845838&postcount=56)? It should not happen until the wear out indictor gets to 1, but we will soon see :)

[Anvil]

Time for a small update, I found an old Intel SSD Toolbox that works with the Kingston. (haven't had the time to modify the latest one yet)

7.32TBW

114424

The only thing that has changed is E9 (Wear out), -1

114425

I changed the Power Plan to "Balanced" and completely forgot to disable hibernation so I ended up with a hibernated computer, not sure for how long, could be 1-2 hours.
(won't do that again :))

The TaskManager showing number of "bytes" written :)
114426

[ImportantAwareness89]

How do I get the Host Writes for my SSD? I have a Crucial m4 128gb

[Computurd]

@ anvil ROFL! that bytes write counter is :) :) :) insane!

very interesting guys, great to see everyone testing, just like the good ol days :) cant wait to see the results of this!

[groberts101]

Very nice commitment here, guys. Will be linking to this thread every time I see someone worrying about every little write to their SSD.

May I suggest that you guys use the 10 [DEC] readout in CDI instead? Helps us to see the numbers without a calculator or being told where they're at now.

using.. Function>Advanced Feature>Raw Values> 10 [DEC].. will show up like so.
http://img857.imageshack.us/img857/8530/cdi.jpg (http://imageshack.us/photo/my-images/857/cdi.jpg/)

Thanks for the effort here. Much appreciated.

[bulanula]

WOW !

Just cannot thank you enough, guys. I really wanted this sort of test done for a while now before I jump on the unproven SSD bandwagon. Time will prove what REALLY happens when the NAND cycles are all used up !

Thanks again !

[Anvil]

May I suggest that you guys use the 10 [DEC] readout in CDI instead? Helps us to see the numbers without a calculator or being told where they'r at now.
...
Thanks for the effort here. Much appreciated.

The hex values are handy as I'm preparing to include SMART in my own application.

I'll see if I can change to decimal when taking screenshots :)
(the most interesting values are still easily readable though)

..

A milestone of 10TB Host Writes was set some time ago.
Media Wearout changed to 93, nothing else of interest has changed, speed hasn't changed either. (each loop takes 495 seconds +/- a few seconds)

More than 3.3 million files have been created so far.

114438

[Roadhog]

Subscribed for turnout. :)

[bulanula]

VERY interesting !!!

The decline in the E9 statistic is not so important. What I am most interested is the end result. How many host writes were needed to make the SSD read only ( if that happens or not is debatable etc. ) !

Just cannot wait. Thanks every so much Anvil and One_Hertz !!! You are doing this for science :)

Just to make sure I have read this right. Does your program accomplish all of these writes through large sequential files or small random files ? If I understood OK it is the latter which would be very nice indeed !

Also, is this the G1 X25-V with 50nm MLC NAND or the G2 X25-V with 34nm MLC NAND ? How filled is it when it comes to static data ( eg windows ) and the rest taken up by your program ? What is the empty space ? Thanks !

[One_Hertz]

We are doing both smaller and larger files with the majority being smaller files. Anvil has a G2 X25-V and I have a G3 320. Both 40GB. We both have around 11GB of static data on it and we are both keeping about 12GB free with the rest of the space being used to write to. Here is what my toolbox looks like so far.

[Computurd]

on a side note...Intel has expanded their warranty on the 320 from three to five years! thats a good warranty, five years. it wqs just announced so they must be pretty confident in the durability of this device. might be harder to kill than we thought!!

http://www.xtremesystems.org/forums/showthread.php?t=271196

[railmeat]

subscribed.

[nn_step]

Here is some already collected endurance information on several drives
http://www.codinghorror.com/blog/2011/05/the-hot-crazy-solid-state-drive-scale.html

[johnw]

Here is some already collected endurance information on several drives
http://www.codinghorror.com/blog/2011/05/the-hot-crazy-solid-state-drive-scale.html

That is just anecdotal evidence of failures. And it does not even include any details about the symptoms of the failures, possible reasons for failures, whether any data could be recovered, and whether the drives were replaced under warranty. Completely useless. Worse than useless, since the systematic data I have seen on failure rates of SSDs shows them to have lower failure rates than HDDs, and this article tends to imply the opposite, without having a credible methodology.

[Ao1]

What's more impressive is that Anvils app generates un-buffered file sizes randomly, so it's a realistic work load. Also no system cache.
My retailer let me down on the V2 (out of stock, despite being shown as in stock). Thanks SCAN. I've ordered another one elsewhere. Should be delivered Saturday.

[railmeat]

That is just anecdotal evidence of failures. And it does not even include any details about the symptoms of the failures, possible reasons for failures, whether any data could be recovered, and whether the drives were replaced under warranty. Completely useless. Worse than useless, since the systematic data I have seen on failure rates of SSDs shows them to have lower failure rates than HDDs, and this article tends to imply the opposite, without having a credible methodology.

"Completely useless. Worse than useless, since the systematic data I have seen on failure rates of SSDs shows them to have lower failure rates than HDDs"

its not useless,its a eye opener.

"since the systematic data I have seen on failure rates of SSDs shows them to have lower failure rates than HDDs"

how is this even possible since ssd,s are still to new(2+yrs) to compare to tried and true veteran (6+ year old) western digital raptors...lol? and sorry raptors are thee only drives worth comparing against any ssd.





im simplying replying from facts from my life.i have had raptors since they were released (36 gigers) in raid o at $250 a pop and ran FLAWLESS for 3-4 years then the 74gigers,then i grabbed 2 raptor-x (clear top)150,s in raid,again flawless.they just last period.plug and play literally.

now as far as ssd,s go they simply have NOT been out Long enough for me to give them any real life credibility or stabilty being i bought 1 crucical c-300 and x58a gig ud3r mobo(tried both ports,all firmware on mobo and ssd done)but it died quickly,like 2 weeks or less with 0 signs of problems,wierd.but man was it fast.fine so i got a ocz vertrex limited editon 100 gig,died 1 week,got another ocz lidetical drive lasted 1 month and i was like wow its ok now,then bam stuttering,slowing down,non-responsive ALOT,had enough and returned that 1 as well.heres my link.are they FAST?...omgosh yes but i simply still dont trust them period for good reasons i witnessed myself 3x.i still think its the intels chipset and not the drives problem reading the ssd instruction set on the ssd controller.i will let time pass,more tests done,let more bugs be worked out.im a gamer,not a guina pig for hardware.need stabilty.

my post
http://www.xtremesystems.org/forums/showthread.php?t=249631&highlight=bootracer






this is NOT a isolated instance and needs not to be down played as one,just the facts being diff ssd,s died period and shows me i was not doing something wrong with my 3 ssd,s i gave a chance.

http://www.codinghorror.com/blog/2011/05/the-hot-crazy-solid-state-drive-scale.html


"Portman Wills, friend of the company and generally awesome guy, has a far scarier tale to tell. He got infected with the SSD religion based on my original 2009 blog post, and he went all in. He purchased eight SSDs over the last two years … and all of them failed. The tale of the tape is frankly a little terrifying:"


•Super Talent 32 GB SSD, failed after 137 days
•OCZ Vertex 1 250 GB SSD, failed after 512 days
•G.Skill 64 GB SSD, failed after 251 days
•G.Skill 64 GB SSD, failed after 276 days
•Crucial 64 GB SSD, failed after 350 days
•OCZ Agility 60 GB SSD, failed after 72 days
•Intel X25-M 80 GB SSD, failed after 15 days
•Intel X25-M 80 GB SSD, failed after 206 days
You might think after this I'd be swearing off SSDs as unstable, unreliable technology. Particularly since I am the world's foremost expert on backups."


i like this thread alot and watching it closely and slowly watching 99-98-97-96-95 on this 1 drive being tested from the op.u dont think i wanna EASILY run out and grab a ocz vertex3 right now.im waiting and letting time prove itself with these drives...

lack of communication is the problem here.intel/amd and all of the major ssd controller manufactuers need to spend ALOT more time together in the labs then a quick "hotfix"


@NN "It's hardware that makes a machine fast. It's software that makes a fast machine slow." agee %100

[johnw]

how is this even possible since ssd,s are still to new(2+yrs) to compare to tried and true veteran (6+ year old) western digital raptors...lol? and sorry raptors are thee only drives worth comparing against any ssd.


Of course we cannot have good statistics on 5 year reliability of SSDs (although we can make good guesses based on tests and data we do have). But that is not the point. The article referenced is pure propaganda since it purports to say that SSDs have a high one or two year failure rate. There is some reasonable data already on one or two year failure rates of SSDs, so it is absurd to give any credibility to the kind of anecdotal evidence the article mentions.


this is NOT a isolated instance and needs not to be down played as one,just the facts being diff ssd,s died period and shows me i was not doing something wrong with my 3 ssd,s i gave a chance.


It absolutely should NOT be given credence. Anecdotal evidence is useless, or worse than useless, when looking at reliability. A careful statistical study with good methodology is required.

The problem with anecdotal evidence is that there are millions of SSDs in use. Even if the annual failure rate is only 0.1%, there should be thousands of SSDs failing each year. All anecdotal evidence tells us is that there are indeed failures -- it gives us no useful information on the failure rate. The useful information that anecdotal evidence might provide is failure modes and how companies deal with warranties. But the referenced article provides nothing like that.

[bluestang]

storagereview.com is wrong. Intel is not the 1st mfg to give a 5 yr warranty on consumer drive....Crucial had a 5 yr on the M225.

[Vapor]

Let's keep the thread on subject :)

[railmeat]

That is just anecdotal evidence of failures. And it does not even include any details about the symptoms of the failures, possible reasons for failures, whether any data could be recovered, and whether the drives were replaced under warranty. Completely useless. Worse than useless, since the systematic data I have seen on failure rates of SSDs shows them to have lower failure rates than HDDs, and this article tends to imply the opposite, without having a credible methodology.


Let's keep the thread on subject :)

:) yes sir

[alfaunits]

This will be nice - I'll know whether my X25-Es died for being an X25-V in disguise :) Thanks for the work guys, truely appreciated.

[railmeat]

This will be nice - I'll know whether my X25-Es died for being an X25-V in disguise :) Thanks for the work guys, truely appreciated.

"Thanks for the work guys, truely appreciated."

agree %100,it is very much so appreciated,thank you.:)


and to mr.vapor.---full respect for the forums:up:

[nn_step]

Of course we cannot have good statistics on 5 year reliability of SSDs (although we can make good guesses based on tests and data we do have). But that is not the point. The article referenced is pure propaganda since it purports to say that SSDs have a high one or two year failure rate. There is some reasonable data already on one or two year failure rates of SSDs, so it is absurd to give any credibility to the kind of anecdotal evidence the article mentions.



It absolutely should NOT be given credence. Anecdotal evidence is useless, or worse than useless, when looking at reliability. A careful statistical study with good methodology is required.

The problem with anecdotal evidence is that there are millions of SSDs in use. Even if the annual failure rate is only 0.1%, there should be thousands of SSDs failing each year. All anecdotal evidence tells us is that there are indeed failures -- it gives us no useful information on the failure rate. The useful information that anecdotal evidence might provide is failure modes and how companies deal with warranties. But the referenced article provides nothing like that.

If you prefer a more careful study. You will have to wait about 1-2 years before the following study will finish:

I have bought 2 of each of the following:

OCZ Agility 3 AGT3-25SAT3-120G
Corsair Force CSSD-F120GB2-BRKT
OCZ Vertex 2 OCZSSD2-2VTXE60G
Corsair Performance 3 Series CSSD-P3128GB2-BRKT
Crucial RealSSD C300 CTFDDAC064MAG-1G1
SAMSUNG 470 Series MZ-5PA128/US
Intel 510 Series (Elm Crest) SSDSC2MH120A2K5
Intel X25-M SSDSA2MH160G2K5
Kingston SSDNow V+ Series SNVP325-S2B/128GB


and am going to subject them to the following actions:

Using a Debian 6.0 Linux box running off of a single 8GB MicroSD card, an undervolted Phenom2, 2GB of DDR2, and a twin set of areca ARC-1231ML-2G PCI Express SATA II (3.0Gb/s) Controller Cards, I will perform a continuous series of reads and writes to the drives until they fail and record exactly how many writes it can actually survive. [The other 3 cores will be dedicated to WCG]

Any questions or comments before I begin the test on May 24, 002011 @ 12noon EST?

[johnw]

Any questions or comments before I begin the test on May 24, 002011 @ 12noon EST?

Wow, that is a lot of money. Do you have a sponsor?

My only comment is that you are missing an Intel 320. That is an interesting drive since it is potentially the most reliable of all consumer SSDs, since it starts with the already reliable X25-M design and adds on XOR parity redundancy. I think it is the only non-Sandforce SSD that uses redundancy.

[Ao1]

Any questions or comments before I begin the test on May 24, 002011 @ 12noon EST?

Good luck. :up: PE longevity is of course dependent on a wide range of factors. Free space, span of writes, speed of writes, xfer sizes, alignment of writes. Tests such as these can only tell you how long NAND will last in a particular set of circumstances. Very useful non the less.

Regarding reliability SSD's haven't been around long enough for long term statics, plus all aspects of the technology are evolving rapidly and at the same time. Add to that the evolving and competitive nature of the industry, which is pushing SSD's on the market that are failing due to a lack of technology maturity and compatibility. The later being mostly responsible for perceived high failure rates.

On the other hand I believe the highest cause of failure for a HDD is mechanical damage. Here SSD's provide a significantly more robust solution with a significantly lower likelihood of failure.

Overall SSD's are a more robust design and in theory (at least) less likely to fail, but not all SSD's are made the same.

Personally I feel very safe using an SSD, but for long term data storage I would only trust a HDD. That primarily comes down to the fact that if a HDD fails there is a lot more chance of getting data of it compared to an SSD.

If I had a laptop I would feel much safer with a SSD.

[nn_step]

Wow, that is a lot of money. Do you have a sponsor?

My only comment is that you are missing an Intel 320. That is an interesting drive since it is potentially the most reliable of all consumer SSDs, since it starts with the already reliable X25-M design and adds on XOR parity redundancy. I think it is the only non-Sandforce SSD that uses redundancy.

No I do not have a sponsor and unfortunately I will not have enough funds to get the 320s until next month. Which will skew their results.



Good luck. :up: PE longevity is of course dependent on a wide range of factors. Free space, span of writes, speed of writes, xfer sizes, alignment of writes. Tests such as these can only tell you how long NAND will last in a particular set of circumstances. Very useful non the less.

Regarding reliability SSD's haven't been around long enough for long term statics, plus all aspects of the technology are evolving rapidly and at the same time. Add to that the evolving and competitive nature of the industry, which is pushing SSD's on the market that are failing due to a lack of technology maturity and compatibility. The later being mostly responsible for perceived high failure rates.

On the other hand I believe the highest cause of failure for a HDD is mechanical damage. Here SSD's provide a significantly more robust solution with a significantly lower likelihood of failure.

Overall SSD's are a more robust design and in theory (at least) less likely to fail, but not all SSD's are made the same.

Personally I feel very safe using an SSD, but for long term data storage I would only trust a HDD. That primarily comes down to the fact that if a HDD fails there is a lot more chance of getting data of it compared to an SSD.

If I had a laptop I would feel much safer with a SSD.

I'd feel much safer with a good backup policy.

[Vapor]

Thread lightly cleaned.

@railmeat, again, please observe the topic. If you want to talk about SSDs dying like it's the Rapture, make another thread, this one isn't the right place.

[railmeat]

Thread lightly cleaned.

@railmeat, again, please observe the topic. If you want to talk about SSDs dying like it's the Rapture, make another thread, this one isn't the right place.

ok sorry np,back on testing topic.;)

[Ao1]

Ok up and running. For now I'm going run it on my main PC so I can keep an eye on it, but later I will probably move it to another PC.

Edit: btw it has Intel 34nm MLC NAND

[railmeat]

awesome :up:

[Ao1]

Hi Anvil, 1 hour in now and I've noticed that after a couple of seconds of a new loop starting that the app seems to hang for ~ 2 or 3 seconds. The MB/s then goes down to ~40MB/s but then speeds pick up as the loop runs. I'm seeing variations from 40MB/s to 180MB/s as the loop finishes.

Do you see that with the X25-V? Maybe it is a TRIM operation?

[Anvil]

Ao1,

What you are seeing is the app is waiting for the OS to finish deleting the files, I'm seeing the same thing here.
From the hIOmon sessions you might remember that the Vertex 2 caused a ~1 second delay while TRIM was purging a single large file.

I've created a new version for you with the option to select a fixed compression level or to randomize compressibility, the latter would be great for the SF drive.

I tested the random compressibility option last night and I ended up with about 16TB/day using 2R0 Vertex 2 60GB. (that raid has about 15GB free space and it has been full for some time)

I'll email you the new version within an hour or so, I've made some adjustments so the not responding message should be gone.

I expect I'm at ~14TB now, will post a screenshot shortly.

[Metroid]

Ok up and running. For now I'm going run it on my main PC so I can keep an eye on it, but later I will probably move it to another PC.

Edit: btw it has Intel 34nm MLC NAND

"DuraWrite, which optimizes the number of program cycles to the flash effectively extending flash rated endurance by 20x or more when compared to standard controllers."

I always wanted to know how much truth is in the quoted phrase, really want to see the end result of this one.

[Anvil]

Yepp, that SF drive should be really interesting :)

Looking at those estimates I wish I'd gone for a faster drive, mine varies from 32-39MB/s, but I'm getting there though, it's just so bl... time consuming.

The 320 that One_Hertz is using is also rather fast compared to mine :), looks like the 40GB 320 is a much better drive than the G2.

[Ao1]

The hangs are getting longer - 6 to 7 seconds. Speeds look to be a lot faster than the Intel drives, but they are varying a lot. 9MB/s after a hang to 140MB/s at the end of the loop.

Still looks like I will catch you up quite quickly at this rate. (Although I'm only at 0.77GB so far).

[Anvil]

Closing on 5 Million files :)

Wearout decreasing at about the same rate and is now at 91, nothing else of interest has changed.

114479

Will be switching to the updated version later tonight, wont be doing any changes to compression on this test as it only matters for the SF drive.

[Ao1]

Hi Anvil, Maybe it would be good to put a summary table on the 1st post to make it easy to compare various milestones?

I have to say so far I am impressed with the Vertex. 3 hours of writes (1.4TB) and although speeds are varying a lot between loops they seem to be staying within the same boundaries. By now I would have thought to have seen evidence of throttling.

EDIT:
LOL, to put a perspective on the writes the X25-M I currently use for my C drive only has 1.32TB of host writes, which occured over 1,263 hours ~ 54 days 24/7. I've already written more than that in 3 hours. (1.5TB)

[Anvil]

I'll see what I can do about that summary.
PM/email me what you'd like to have in that summary.

Yeah, I don't think most people are actually getting how much data is written.
I've got one Kingston thats been running for more than 10,000 hours and its still short of 1TB Host Writes. (running as a boot drive on a server, not much happening but still it's running 24/7)
I'll check the two other 40GB drives I've got (both Intels), they are both used as boot drives as well but not running 24/7.

I'm pretty sure that 10-20TB Host Writes is what most of these drives will ever see during their normal life-span (2-3 years), unless they are used in non-standard environments.

[Ao1]

Anvil, here is a shot of the performance monitor that shows the "hang". No worries though it's running great. :up:

I don't know if I should switch over to the new version and use compressible data. On one side it is fairer to the Vertex, but on the other side it prevents a direct comparison to the Intel drives.

[Anvil]

Just keep/rename the old app and give the new one a try.

You could use 8% (Database) which is still easily compressible, it will make an impact on the TB/day rate but I'm pretty sure it will be more correct vs the Intels.
If the impact is too high (it really shouldn't be) then you can still select 0-Fill or return to the old app. (there is a tab for settings in the new version)

Maybe you should give hIOmon a shot as well, just a few minutes would be interesting.

edit:

Here's the X25-V's that I'm currently using in my main rig (the 980X)
A lot of activities like surfing but no large apps are installed, they all run on the Areca in VM's.
VMWare Workstation is of course installed on the X25-V, no pagefile though as there's plenty of memory.
114483

So, 939.63GB of Host Writes in 4187 hours. (~230MB/hour)

[bulanula]

Really eager to see what these drives can take !

Thanks everyone !

[Ao1]

I had to reboot to get hIOmon running on the OCZ drive, so the stats below only cover a 0.5TB. Plenty of TRIM activity, but nothing that shows anything more that a ~ 0.4s delay.

I'm a bit taken a back. 3TB of writes in 6 hours and still on 100% life. No sign of a significant slowdown either.

Edit: Anvil, a summary of writes vs wear out % for each drive in the 1st post would be handy. I've got a feeling this will end up being a very long thread, so having something in one place will make comparisons a lot easier.

[alfaunits]

Hmmm ~500GB, ~900.000 IOPS - that's ~512KB average write size - Anvil, isn't that a big too big for randomness?
3TB written - perhaps it was compressed (which considering the speed of 140MB/s I would guess it is), so the actual NAND use is much less?

[Ao1]

For now I am using V1.0.0 of Anvils app, which is the same version Anvil & One_Hertz are using.

[Anvil]

I'm reinstalling my benchpc, will make that summary as soon as it's back up.

So, 75% is considered being random writes, that is quite high, considering that they are all sequential by nature :)

@alfaunits
50% are < 128KB and the other half are from 1KB up to 12MB.
(every file is randomly sized)
It's as close as it gets to the mix we need for keeping up the pace.

Realistic?
For some the avg filesize might be on the large side, for others its's low.

[overthere]

Hi Anvil,

A couple of quick questions:


How many separate files are being written to concurrently within a loop?

For each separate file, is the entire file being written by a single write I/O operation to the file?
Thanks ...

[Anvil]

Hi Overthere

Glad you asked :)

A file is written either using 1 io or using 3 ios, max blocksize/transfersize is 4MB, it needs some more explaining so here we go.

50% of the files are created using one write operation with a max blocksize of 128KB, as for the other half
each file consits of exactly 3 WriteFile operations, each IO can be up to 4MB in size, so it is sort of random. (even though the data is written sequentially)

edit:
Forgot the first one
This test is single threaded, so, 1 single file at a time.

[Ao1]

I can't believe it. 4TB of writes, no slowdown and still showing 100% life after 8 hours.

Hi overthere. :) If you would like the log files please see pm.

[johnw]

I can't believe it. 4TB of writes, no slowdown and still showing 100% life after 8 hours.


How much is actually being written to the flash? In other words, are you sending compressible data to the SSD? I think the only repeatable way to test a Sandforce SSD is to write random data, since writing anything else will result in an unknown compression factor.

[Ao1]

Anvil, I've just switched the new app you sent me. I used the 100% uncompressible setting and things look very different. Avg ~ 42 MB/s. Those files in the first app must have been near 100% compressible.

[overthere]

...A file is written either using 1 io or using 3 ios, max blocksize/transfersize is 4MB, it needs some more explaining so here we go.

50% of the files are created using one write operation with a max blocksize of 128KB, as for the other half
each file consits of exactly 3 WriteFile operations, each IO can be up to 4MB in size, so it is sort of random. (even though the data is written sequentially)...
Thanks for the explanation!

Looks like the file I/O operation activity as described basically coincides with the random/sequential metrics observed by hIOmon further down at the "physical disk" level within the Windows OS I/O stack.

I think that it's important to distinguish between I/O operations performed "logically" within a file and the I/O operations subsequently performed at the "physical device".

As you mentioned, writing to a file can consist of three successive "sequential" write file I/O operations (which together comprise the entire length/size of the file).

However, each of these three write file I/O operations can actually be to non-contiguous locations upon the device. And so, hIOmon observes the three write I/O operations to the device as "random" write I/O operations.

Filesystem (re)allocation of clusters can also be a factor - but I don't want to go off topic here. ;)

In any case, many thanks to you, Ao1, and One_Hertz for undertaking this exercise! :up:

[Vapor]

Anvil, I've just switched the new app you sent me. I used the 100% uncompressible setting and things look very different. Avg ~ 42 MB/s. Those files in the first app must have been near 100% compressible.If the peanut gallery gets a vote, I'd like to see a combination load. Realistic loads are neither fully incompressible nor fully compressible.

:2cents:

[johnw]

Anvil, I've just switched the new app you sent me. I used the 100% uncompressible setting and things look very different. Avg ~ 42 MB/s. Those files in the first app must have been near 100% compressible.

I think 100% incompressible is the best choice, at least for a first test. That way anyone who wants to try to repeat your measurement can do so.

[johnw]

If the peanut gallery gets a vote, I'd like to see a combination load. Realistic loads are neither fully incompressible nor fully compressible.


That complicates things needlessly. Just how compressible is a "realistic load"? And how much does the Sandforce actually compress when given typical data? (not very much, I think). Better to stick with incompressible data so that the test is repeatable and we know how much is actually written to the flash.

[Anvil]

Ao1,
Try using the Randomize compressibility, it would be very close to real life IO as it would be a complete mix of the different levels of compression that are available.
I'll switch to the new version shortly, it won't change anything for the Intels though.
The incompressible level you selected is actually 101% as it's totally incompressible. (it would result in a file of 101% of the original using 7Zip)

Overthere,
I can see that hIOmon sees it that way and I don't think it can do otherwise.

@johnw

There aren't that many files that are incompressible, mp3, jpg, png, raw image files from DSLRs are all examples of so called incompressible files.
Programfiles, dll's, documents, most temporary files, datafiles, windows log files are usually easily compressible.

Unless you are solely working with images, producing mpegs there is bound to be a lot of easily compressible data.
You'd be surprised, try making a backup image of your C drive using e..g Acronis TrueImage, it is very likely that it would be somewhere between 33-50% of the acual size.

[Vapor]

I think 100% incompressible is the best choice, at least for a first test. That way anyone who wants to try to repeat your measurement can do so.I think 100% is the best test for NAND durability (and parity scheme, I suppose). But if you're entering a SF into the test, one of its big features that sets it apart is the compression and negating it doesn't represent what the SF can do (for most usage models).

I'd like to see both tested, of course, but the Call for MOAR in testing is always there :lol:


That complicates things needlessly. Just how compressible is a "realistic load"? And how much does the Sandforce actually compress when given typical data? (not very much, I think). Better to stick with incompressible data so that the test is repeatable and we know how much is actually written to the flash.Take what you have on a drive, copy it to another, compress the files with the 2nd lowest level of RAR compression (lowest being 0 compression, just making a single file out of many), observe compressibility :)

[Ao1]

I kept hIOmon running so the stats below reflect the data from both versions of the app, however straightaway the max response times have jumped up following the switch to non compressible data.

I believe the Max Control (4.69s) is a TRIM related operation (?)

MB/s is swinging from 20 to 40MB/s

Got to pop out for a bit, will switch more compressible data later.

[frostedflakes]

That complicates things needlessly. Just how compressible is a "realistic load"? And how much does the Sandforce actually compress when given typical data? (not very much, I think). Better to stick with incompressible data so that the test is repeatable and we know how much is actually written to the flash.
AnandTech mentioned in the Vertex 3 preview I believe that all of their in-house SandForce drives had a write amplification of about 0.6x. So assuming a write amplification of 1.1 for incompressible data (seems reasonable since that's what Intel and other good controllers without compression/dedupe can achieve), as an OS drive it can compress host writes by about 45% on average.

I think it would be far more valuable to see how well the SF controller can deal with more realistic workloads like this than completely compressible or incompressible data. But just my $0.02. :)

[johnw]

AnandTech mentioned in the Vertex 3 preview I believe that all of their in-house SandForce drives had a write amplification of about 0.6x. So assuming a write amplification of 1.1 for incompressible data (seems reasonable since that's what Intel and other good controllers without compression/dedupe can achieve), as an OS drive it can compress host writes by about 45% on average.


I read that, too. The problem is that it is likely a bogus number, since Anand's drives get a lot of benchmarks run on them which write highly compressible (and unrealistic) data.

I think what you are talking about should be a separate experiment. You could put monitoring programs on computers to record months of writes, and then find a way to play those writes back and determine how much Sandforce can compress them.

But for this experiment, I think it is important to know how much data is actually written to the flash, and the only way to know that with a Sandforce drive is to use random data.

Random data also has the benefit of being a worst-case scenario for Sandforce, and I think that is what is most valuable to know, since then you can state with confidence that a more typical workload will likely result in a drive lasting AT LEAST X amount of writes. Anything other than random data and you have to make wishy-washy statements like, well, it might last that long, but if you write data that is less compressible, it will probably last a shorter time.

[frostedflakes]

I got the impression from the article that these weren't review drives. So the WA should be typical of what a regular user would see if they used it as an OS drive.


Thankfully one of the unwritten policies at AnandTech is to actually use anything we recommend. If we're going to suggest you spend your money on something, we're going to use it ourselves. Not in testbeds, but in primary systems. Within the company we have 5 SandForce drives deployed in real, every day systems. The longest of which has been running, without TRIM, for the past eight months at between 90 and 100% of its capacity.
http://www.anandtech.com/show/4159/ocz-vertex-3-pro-preview-the-first-sf2500-ssd/2

You're right about it being a good indicator of worst-case durability, though, and we could still extrapolate about more ideal situations with more compressible data from this.

[johnw]

I got the impression from the article that these weren't review drives. So the WA should be typical of what a regular user would see if they used it as an OS drive.


I read that, too. I still think you are wrong about those drives seeing "typical" use. Do you really think that the guys using those drives aren't playing around and running a boatload of benchmarks on them? I seriously doubt Anand's crew bought Sandforce drives and gave them to "typical" users to work with, without playing with them themselves first.

[Ao1]

Here are the options in Anvils app. I could run at 100% incompressible for an equal time that I ran the 0 fill - I would then be at ~50%. I could then go to the 46% or I could just carry on with 100% incompressible?

I'm inclined to keep at 100% incompressible but if there is a consensus otherwise I can do whatever. :shrug:

[Anvil]

46% is much more realistic than incompressible, a mix would be interesting though.

Too many options with that drive :)

Added a graph to the first post, have a look at it, if thats going to work we need to agree on milestones where we give input.

[Vapor]

Make the chart an XY rather than a line graph...any input pair on the X and Y axes will work, rather than set milestones. :)

Also, no need for the 3D effect :p:

[Computurd]

But for this experiment, I think it is important to know how much data is actually written to the flash, and the only way to know that with a Sandforce drive is to use random data.

yes, impossible to have a 'control' when dealing with unknown compression factors/percentages.

[johnw]

46% is much more realistic than incompressible, a mix would be interesting though.


I think you are being imprecise -- you have just lumped together at least 3 questions, which is bad experimental procedure:

1) What exactly does this 46% data consist of, and how can someone duplicate it if they want to try to repeat Ao1's experiment?

2) Is the data that you call 46% a realistic representation of data that many people will be writing to their drives?

3) How much does the Sandforce drive actually compress the data you call 46%?

Dealing with (1) is a hassle, since the exact data specification would need to be written and posted, and anyone wanting to repeat the experiment would need to carefully duplicate the exact data.

Questions (2) and (3) are very difficult to answer, and even if they could be answered, I think we do not know the answers at this time.

Better to sidestep all of those issues and go with completely random data.

[johnw]

I'm inclined to keep at 100% incompressible but if there is a consensus otherwise I can do whatever. :shrug:

I think you should keep it at 100% incompressible. It is the best experimental procedure. After you have done the control, you or someone else could always try one of the other options. But random data is definitely the way to go for the control.

[Vapor]

Here are the options in Anvils app. I could run at 100% incompressible for an equal time that I ran the 0 fill - I would then be at ~50%. I could then go to the 46% or I could just carry on with 100% incompressible?

I'm inclined to keep at 100% incompressible but if there is a consensus otherwise I can do whatever. :shrug:Depends on what question you're most interested in answering. If NAND durability is the question, 100% incompressible. If SSD durability is the question, definitely not 100% incompressible or 0-fill data. None of us know what the 'world average' is for data compressibility, but I bet we can all agree not at (or near) either extreme :)

With WinRAR, I took my C: and D: drives and looked at what kind of compressibility they have.

C: drive (Windows + applications) was able to be compressed to 55.2% of the original size with the fastest compression algorithm.

D: drive (documents + photos) was able to be compressed to 79.4% of the original size with the fastest compression algorithm.

Real world data is somewhat compressible with even lightweight algorithms.

So, yeah, if you're interested in seeing when the NAND dies out, do 100% incompressible and take the controller's dedup/compression out of it (although parity schemes will still be a factor). If you're interested in seeing how the controller can mitigate some NAND wear (relative to the X25-V which has the same NAND [right?] but different controller), test with the 46% (seems to be the least compressible, but still compressible, option).

I do agree that 100% incompressible with the SF controller is something that should be tested, but picking between 100% incompressible and somewhat-compressible data, I'd have to pick somewhat-compressible to be tested first.

[johnw]

With WinRAR, I took my C: and D: drives and looked at what kind of compressibility they have.

C: drive (Windows + applications) was able to be compressed to 55.2% of the original size with the fastest compression algorithm.

D: drive (documents + photos) was able to be compressed to 79.4% of the original size with the fastest compression algorithm.

Real world data is somewhat compressible with even lightweight algorithms.


But MUCH less compressible by a Sandforce controller than your test might indicate. I doubt the controller can have a power budget of more than 1 W. And it has to compress general data at a rate of hundreds of MBs per second in a single pass. Whatever algorithm it is using cannot be very good -- certainly not as good as even the fastest WinRAR algorithm.

Anand hypes the compression of the Sandforce controller, but I think he (and many others) greatly overestimate the compression that can be achieved on realistic data under such difficult conditions as real-time SSD data compression.

[Anvil]

The question is, what do we want to know?

100% incompressible data is of course an option as long as the static part of the drive is filled with realistic data, e.g. a Windos 7 installation.

100% incompressible data is just not possible as long as the drive is used as an OS drive, OS and applications are roughly 50% compressible, possibly more if one uses the pagefile.

By using 100% incompressible data it would mean that the answer one would get is, the quality of the NAND used, the abilty of the SF controller to do wear-levelling of both static and dynamic data, (can't think of any others right now) but one of the main points with the SF controller would be totally lost, which is compression.

Of course I agree with you about what is a proper way to conduct such a test, which in short = knowing all the varialbles.
Real-Life just isn't like that, so we need a lot of SF drives to get the anwers we want.

To answer your question about 46%, it's just a level of compression that is a likely average for all files on your OS drive. (an SSD in particular, storage excluded)

From what I've found playing with compression on the SF 12XX controller there aren't that many "levels" of compression.
Meaning that when you reach a certain level of compressibility it doesn't matter if the data is e.g. 30 or 40 percent compressible, they are handled with the same speed.

We can't get all the answers using 1 SF drive so it's just a matter of making a decision about whats more important.

edit:
reading Vapors post...
---
We need more SF drives to get to the answers :)

[johnw]

100% incompressible data is just not possible as long as the drive is used as an OS drive, OS and applications are roughly 50% compressible, possibly more if one uses the pagefile.

....

From what I've found playing with compression on the SF 12XX controller there aren't that many "levels" of compression.
Meaning that when you reach a certain level of compressibility it doesn't matter if the data is e.g. 30 or 40 percent compressible, they are handled with the same speed.


The data may be "50% compressible" by a standard compression program, but it is unlikely that the Sandforce controller can achieve such a level. Possibly what you are seeing with your levels of compressibility test is an artifact of the data you are using. It is very difficult to achieve set levels of compression without mixing together random and highly compressible data in some pattern. But that does not necessarily model real data very well.

[Ao1]

Here is a screen shot on a fresh run with the 100% non compressible option.

Anvil are you sure the xfers are 100% non compressible?

[Vapor]

We need more SF drives to get to the answers :)Agreed. :p:

How much are F40/V2-40s? :lol:

[Anvil]

Here is a screen shot on a fresh run with the 100% non compressible option.

Anvil are you sure the xfers are 100% non compressible?

The 100% Incompressibe option will result in a 101% file, it's not even possible to do deduplication on that file. (I've checked with 7Zip)

I'll do another test and see of something has changed.

I expect you can do about 40-50MB/s on that 40GB drive using incompressible data, don't know what/if throttling would make it worse.

edit:
Here'se a few samples of the original vs the compressed file.
114510

I'll do a few tests but it's looking as designed.


@Vapor
The 40GB should cost < $100.

[johnw]

The 100% Incompressibe option will result in a 101% file, it's not even possible to do deduplication on that file. (I've checked with 7Zip)


How much random data does your program have, and how much does it write before the same random pattern repeats (if it repeats)?

In other words, a bad way to do it would be to have 512 Bytes of random data, and to write that same 512 Bytes over and over. A better way to do it would be to have many megabytes of random data before it repeats, or even generate the random data on the fly (if it can be done fast enough) and not have any repetition. Based on your data, I guess any repetition must be at least 11MB or more apart, since the 11,432KB file cannot be compressed by 7Zip. But what about the smaller files, like the 1KB one. If it happens to write two small files in a row, say 1KB and then 4KB, is the random data in the second file different than the random data in the first file?

[Anvil]

The data is created on the fly, nothing is repeated, if it was it wouldn't work.

As long as the random data generator is active it creates fresh random data for every write.

So yes, it looks like you've got the point about repeating data right.

The issue here might be that the CPU could already be a bottleneck for generating the random data, I'll have to do some tests.

[johnw]

The data is created on the fly, nothing is repeated, if it was it wouldn't work.


Repeating could work, if you had a large enough data set. You could pre-generate, say, 1GB of random data, load it into memory, and then just step through it, 512B at a time. Theoretically, some deduplication algorithms could compress that once you got through the first GB and started repeating, but I seriously doubt the Sandforce controller can do that, especially if you changed the offset on successive runs through the data. (But it might be able to if you repeated after 4KB, say)

[Anvil]

The buffer is 4MB in size, the random data generator generates only whats needed so if the file is supposed to be 4KB it generates exactly that.

Huge sets of memory could possibly work but there would be overhead using that model as well.

I have no idea about how advanced the SF controller is but I bet it's pretty good, I'm also quite sure that we're already overdoing it.
The 100% option does produce 101% files using 7Zip and that is a 1% penalty for the SF controller, not much for a few small files but for Millions of files it makes a difference.

I'm pretty sure that at some given level of compression it will simply store the data as is.

SF did once say that a full W7 + Office installation that normally would generate 25GB of writes ended up as 11GB of "stored" data.

There is also the option of using encrypted data, haven't really read up on how that impacts the SF controller.

[Ao1]

Here is a comparative shot when writing 100 uncompressible data. It's the same scale as the screen shot in post #66 (http://www.xtremesystems.org/forums/showpost.php?p=4855288&postcount=66)- 0.1, but I have zoomed in to get more detail.

I can see the same "hang" just after a new loop starts.

Avg write is 48.32MB's (according to hIOmon) The highest ResponseTime_Max_Control is 5.215s.

Despite the overwhelming evidence I'm a bit suspicious that somehow compression is still occurring to some extent.

5.76TB writes/ 100% life

[Ao1]

Opps I just noticed that in the 1st screen shot in post #66 the logical disk is being monitored. In post #106 I captured the physical disk level. They both read the same anyway.

[johnw]

Huge sets of memory could possibly work but there would be overhead using that model as well.


Yes, infinite speed is not possible. :D
But memory bandwidth is many GB/s -- well over 10 GB/s on recent DDR3 systems.

[johnw]

The buffer is 4MB in size, the random data generator generates only whats needed so if the file is supposed to be 4KB it generates exactly that.


One more question. Are you sure you are not re-seeding the random number generator (with the same seed) each time you generate a new file? That would obviously result in repeated data.

[alfaunits]

However, each of these three write file I/O operations can actually be to non-contiguous locations upon the device. And so, hIOmon observes the three write I/O operations to the device as "random" write I/O operations.
On an SSD whether the logical LBAs are sequential or not plays absolutely no role - their physical location is so random, even 64 writes of 4KB each at consecutive locations can be on 64 different (and thus random) locations.
What I am trying to say is that whether some I/O is considered random by hIoMon on an SSD has little to do with whether that I/O is truely random.
Since the app is singlethreaded, essentially any <=4KB can be considered random and anything over would be sequential.


Filesystem (re)allocation of clusters can also be a factor - but I don't want to go off topic here. ;)
Doesn't matter if TRIM is in effect. Whether the FS allocates them on another free cluster or existing free cluster is of no importance on SSD physical level, literally.
I believe NTFS has CPU optimizations in that area for SSDs (i.e. take the road with the least CPU cycles consumed vs. "best placement" that would be used for HDDs).


The incompressible level you selected is actually 101% as it's totally incompressible. (it would result in a file of 101% of the original using 7Zip)
A side note, 7Zip uses extreme compression technique, SF probably uses plain ZIP or LZ like NTFS. The maximum data block is likely 64KB or maybe even less (random presumption for SF, it's 64KB for NTFS). If it can't be compressed it just isn't. It won't store more than the original. 7Zip does depending on the compression settings.


I think 100% is the best test for NAND durability (and parity scheme, I suppose). But if you're entering a SF into the test, one of its big features that sets it apart is the compression and negating it doesn't represent what the SF can do (for most usage models).
But testing with somewhat compressible data even will negate the amount of data written to the NAND which in turn negates the purposes of these tests :)
Even though it can write the compressible data at 140MB/s, what is to stop it from actually compressing it to 1% of its size if it's compressible so?


Take what you have on a drive, copy it to another, compress the files with the 2nd lowest level of RAR compression (lowest being 0 compression, just making a single file out of many), observe compressibility :)
And then see the CPU utilization and the "speed" of compression compared to what NAND can do :)

[Ao1]

I left the endurance test running overnight with non compressible data. Avg MB/s has not changed (according to hIOmon) its still 48MB/s.

7,168TB/ Life 100%. The only thing that has changed:

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

Something does not seem right. The drive is not performing as expected, i.e writes are showing no sign of being throttled and the blocks aren't wearing. :shrug:

According to a post by tony:

"Let me put this into plain English. You buy a 60GB drive, you install win7 to it. Average install can be around 16 to 20GB. You then bench the drive with a benchmark such as CDM or AS-SSD that writes incompressible data.

What happens?

1st all writes go thru the OP on the drive, on a 60GB drive OP is around 8GB, if the benchmark writes more than 8GB the drive will now be erasing blocks before writing to blocks as only OP area is kept clean.

2nd, The drive sees a constant stream of high volume writes, Duraclass kicks in to limit write speed to ensure longevity of the nand on the drive. It does this for a fixed period of time, it can be hours or days.

3rd, the drive now goes into recovery mode...this is dictated by the Duraclass and the amount of writes the drive has seen in a fixed period of time.

This is what end users see as a speed loss, there is also an additional drop in speed from an unmapped drive to a mapped drive regardless of whether the drive has seen short burst high volume writes but I disregard that drop as Duraclass is a needed function of the drive and its effect is inevitable...
I prefer to use the terms used drive performance and hammered drive performance.

used = fully mapped day to day speed.

hammered = benched to full, massive amounts of incompressible data written in a short time period."

[Ao1]

OK, I stopped the test and ran AS SSD. Clearly the SF drive is somehow compressing the test files in Anvils apps.

[Anvil]

One more question. Are you sure you are not re-seeding the random number generator (with the same seed) each time you generate a new file? That would obviously result in repeated data.

Yes, I'm sure :)

I just checked and it is not being seeded at all during the Endurance test.
(meaning it's using the default seed in the test)

I've been working a lot with this exact problem when creating the SSD Benchmark that's getting close to being ready for beta.
I've been through all the possible phases of buffer/blocksize vs repeating blocks and 7Zip is a pretty good check for this.

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.

[Anvil]

@Ao1

Could you try running a CDM on that drive, the AS SSD test is a good indication but not a reference.
AS SSD uses a 16MB "file" for testing the sequential speed.
Also, random 4K is performing better than Sequential writes, which is a bit odd.

As long as you selected 100% it's doing exactly that.

I have yet to see any of my SF drives showing < 100%, so it's not exceptional considering that you did run quite a few TB with easily compressible data.

[Ao1]

How shall I run CDM? (0 fill or full?)

[Anvil]

As it's all about wear you can do both but 0-Fill = easily compressible data and Full (normal) equals incompressible data.

Also, I've checked with ZIP and LZ and they are both agreeing with 7Zip, the file is larger than the original using ZIP and is simply stored using LZ.

I'll send you an update anyways as I've added 67% compression and done a bit of fine tuning in the loop wrt compression.

Here is a Perfmon of the transition from Writing->Deleting->Start Writing files again.

114532

It does look like that period is a lot different from mine, imho, that is TRIM working on the SF drive.

I'm using the Intel driver btw, are you using the Windows default or the Intel one?
(could be significant as there is a "bug" in the MS one)

[Ao1]

I ran non compressible whilst waiting. I'm running 0 fill now for comparison.

[Ao1]

0 fill option. So it seems that compressible data does not get throttled.

This really seems to imply that the endurance test is somehow being compressed as speeds have not changed throughout. :shrug:

[Anvil]

Yes, I'm 100% sure it's working.

The CDM run confirms that it's working.

So, where is the throttling? :), 40-50MB/s is pretty good for that small drive if it's being throttled.

Did you have a look at my perfmon graph?

[Ao1]

It does look like that period is a lot different from mine, imho, that is TRIM working on the SF drive.

I'm using the Intel driver btw, are you using the Windows default or the Intel one?
(could be significant as there is a "bug" in the MS one)

I was going to ask you to run perfmon :) What I notice is that the hang happens just after the loop starts. It looks very much like a TRIM operation is causing the "hang". The hang duration coincides with ~5 seconds that are recorded against the "responsetime_max-control, which I believe is TRIM related. (Hopefully overthere can confirm.) Either way the hang seems to be much more that the test files being deleted.

I'm running RST (10.5.0.1022)

[Anvil]

Time for another update

114534

Media Wearout has just dropped to 89.

> 5,7 Million files have been created.

edit:
I'm using RST 10.5.0.1026/27

[Anvil]

A new take on the graph

114535

I don't think the Wearout Indicator is the one to use but until then.

[railmeat]

I was going to ask you to run perfmon :) What I notice is that the hang happens just after the loop starts. It looks very much like a TRIM operation is causing the "hang". The hang duration coincides with ~5 seconds that are recorded against the "responsetime_max-control, which I believe is TRIM related. (Hopefully overthere can confirm.) Either way the hang seems to be much more that the test files being deleted.

I'm running RST (10.5.0.1022)

my ssd,s hung....never understood. :l thanks for making this post guys.:up:

[One_Hertz]

20.5TB. 90 wear indicator.

[Ao1]

I'm on Version 3 of the SSD slayer now.

I'm going to keep running it on the uncompressible option, otherwise this experiment will never end. I'm just coming up to 8TB and I'm still at 100%.

Some observations/ thoughts:

• When TRIM executes it seems to lock the drive until the command is finished.
• It seems that the hang duration whilst the TRIM command is being executed is the same, regardless if the data is compressed or not.
• It must be a bit tricky for the SF controller to translate the OS TRIM command to the compressed data on the SSD. Either way a TRIM command with an Intel SSD seems to be more seamless. Perhaps it TRIM's more frequently or it can do it without locking up the drive at the same time.
• SF throttling seems to only really effect sequential speeds and 4k random speeds at high queue depth. 4K reads @ QD1 seem unaffected, although 4K random writes take a hit.
• Strangely SF drives throttle both read & write sequential speeds (why reads?)
• Even in a throttled state the V2 is faster that the 320 & the X25-V. (based on what is being reported by Anvil's app).
• The X25-V and 320 are exhibiting near linear wear based on the SMART info.
• Either the V2 has significantly better wear levelling or the SMART data is not as accurate.

EDIT:

Not sure what happens in Zone B. The Loop finishes at point A. It appears to start a new loop, but a couple of seconds later it locks up. Anvil's graph shows the same peak just after the loop finishes, but there is then no delay as can be seen in zone C below. It's the same pattern every time and it only happens just after the new loop starts. Sometime more pronounced other times its less pronounced.

One_Hertz, any chance of running perfmon to see how the 320 handles it?

[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

114543

Doesn't look like anything happened during the deletes :)

HDD-SSD : 1-0 :p:

[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 (http://www.xtremesystems.org/forums/showpost.php?p=4855210&postcount=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 :p:

[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 :D

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

[Ao1]

11.6TB.....Wear out 99%.

[One_Hertz]

24TB. 88.

Ok this workload is much too light. All we are doing is sequentially writing to the SSD and slowly wearing out the NAND. 2TB per percent that I am seeing right now would mean 200TB to reach 1, or 5000 cycles on each NAND cell, which happens to exactly be the spec.

Anvil, how about adding some random writes, meaning, making changes within the generated files?

My 320 has the TRIM hang you speak of as well, but it only lasts 1.5-2 seconds. After this, the speed drops to about 39MB/s over the period of 30 seconds. During the next 30 seconds it slowly recovers to 42-43.

[Ao1]

My 320 has the TRIM hang you speak of as well, but it only lasts 1.5-2 seconds. After this, the speed drops to about 39MB/s over the period of 30 seconds. During the next 30 seconds it slowly recovers to 42-43.

That is more or less exactly what I am seeing. (Except hangs are longer).

If you go by perfmon the hang is near on a 10 second duration. hIOmon however shows ~5 seconds. I'm inclined to believe hIOmon.

[Anvil]

11.6TB.....Wear out 99%.

Finally :)


24TB. 88.
Anvil, how about adding some random writes, meaning, making changes within the generated files?


I can do that, although a lot of these writes are actually "random".
What I can do is to enable part of th benchmark and have a fixed 1-2TB file where random writes takes place at some interval.
Those writes would never be handled by TRIM as TRIM can only do cleansing when a file is "deleted".

edit:
The TRIM hang is more like One_Hertz's except for that it building up speed for a short while and within a few minutes it slowly drops to about 32-33MB/s. (it peaks at ~39MB/s)

[johnw]

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.


Anvil can confirm (or deny), but I suspect the program is sending TRIM commands for a large number of files at once. Thousands?

For streaming video or audio, I don't think most people are likely to have thousands of files to delete at once. Or if they do, they are doing something wrong.

[Anvil]

Yepp, I can confirm that we are talking about thousands of files, but, I'm pretty sure it's more related to the size (in GB) of the files rather than the number of files, could be both of course.

[Ao1]

Anvil can confirm (or deny), but I suspect the program is sending TRIM commands for a large number of files at once. Thousands?

For streaming video or audio, I don't think most people are likely to have thousands of files to delete at once. Or if they do, they are doing something wrong.

Someone should try streaming a video to a Vertex drive and then we would soon know. I can stream audio so I'll try that later. I doubt if it matters much what has been written, in terms of how many files were generated. I'd guess it's about how large the TRIM operation is, i.e. the total size of data to be TRIMMED.

Anvil, I had a look at the OCZ fw release notes and I see it is indeed documented. I was not aware of the beforehand.

Known open issues:
•TRIM command response times are longer than desired

EDIT: Anvil I'm guessing all the temp files are deleted at the same time, i.e at the end of a loop?

[Anvil]

Closing in on 20TB
114575

6,7 Million files :)

I'll update the 1st post with an updated graph a little later.

[johnw]

Yepp, I can confirm that we are talking about thousands of files, but, I'm pretty sure it's more related to the size (in GB) of the files rather than the number of files...

I'd take the opposite side of that bet. I think that if you send a TRIM with thousands (or millions) of LBAs, it is going to take a long time. But if you send a single TRIM with contiguous LBAs, say, 2048 - 40,000,000, that it will not take so long.

[Ao1]

I can stream audio and set the file to split at 64MB, 650MB, 700MB or 2,048MB. (By using Tracktor).

I can also stream in any audio format. Wave eats up disk space. EDIT: but can be compressed to 10th the size by converting it to an mp3)

Going start working on it now, so we will soon see.

[Anvil]

I'd take the opposite side of that bet. I think that if you send a TRIM with thousands (or millions) of LBAs, it is going to take a long time. But if you send a single TRIM with contiguous LBAs, say, 2048 - 40,000,000, that it will not take so long.

Both would be directly related to the # of LBAs.
In my case the 1.5 second delay was caused by deleting 1 single file. (a 1,5GB file)
Now how would that translate to a single 15GB file?, would it be 15 seconds?
The amount of data deleted by Ao1 is approximately 15GB.

I don't know, hIOmon lists the LBA range for TRIMs but I don't think it would for thousands of files.

[Anvil]

@alfaunits

Here is a sample testfile.

[overthere]

...It looks very much like a TRIM operation is causing the "hang". The hang duration coincides with ~5 seconds that are recorded against the "responsetime_max-control, which I believe is TRIM related. (Hopefully overthere can confirm.)...
Ao1 is correct regarding the "ResponseTime_Max_Control" shown within the hIOmon WMI Browser reflecting the maximum response time observed by hIOmon for a "TRIM" command (technically, a "Device Control" I/O operation that specified a "Manage Data Set Attributes (MDSA)" request for a "TRIM" action).

When the hIOmon "SSD I/O Performance Analysis Add-On" script configuration option is used, the hIOmon software is specifically and automatically configured to monitor control I/O operations for the specified physical volume/device(s); read and write I/O operations can also optionally be monitored by hIOmon.

Moreover, this monitoring of control I/O operations by hIOmon is limited to "MDSA" requests (consequently, other control I/O operations such as Flush Buffers are explicitly ignored by hIOmon).

So overall in this case, the various "control I/O operation" metrics captured by hIOmon reflect TRIM-related control I/O operations only. Similarly, the "control I/O operation" metrics shown within the hIOmon Presentation Client displays provided by Ao1 also reflect only TRIM-related control I/O operations.

[Ao1]

^ this makes things very easy :)

Here are some results from 3 delete operations. Nothing else is running in the background.

What I notice; TRIM only occurs when the file is deleted from the Recycle bin. In all cases there is a delay of a few seconds before the TRM command is executed.

This tells me that when running the loop, as the new loop starts it is stopped by the TRIM command being executed a couple of seconds after the delete has occured.


File folder = 612MB 179 files in 4 folders
AVI = 697MB
File folder = 6.83GB 635 files in 96 folders

[Anvil]

EDIT: Anvil I'm guessing all the temp files are deleted at the same time, i.e at the end of a loop?

Yes, the files are deleted one by one.
The writing doesn't re-start until all the files are deleted.

[overthere]

...hIOmon lists the LBA range for TRIMs but I don't think it would for thousands of files.
hIOmon can collect I/O operation metrics that are automatically summarized as well as an I/O operation trace. Both of these options can be used separately (with no dependence upon each other) or concurrently.

Some of the "summarized" TRIM-related metrics captured by hIOmon are shown within Ao1's prior post #84 (http://www.xtremesystems.org/forums/showpost.php?p=4855616&postcount=84) using the hIOmon WMI Browser.

Similarly, Ao1's post #125 (http://www.xtremesystems.org/forums/showpost.php?p=4856445&postcount=125) shows a snippet from a hIOmon Presentation Client display that includes several control I/O operation metrics which are TRIM-related.

The hIOmon Presentation Client can be configured to display additional TRIM-related metrics as shown in Anvil's post #148 (http://www.xtremesystems.org/forums/showpost.php?p=4616928&postcount=148) post within the hIOmon thread. A brief description of these metrics is provided within the subsequent post #149 (http://www.xtremesystems.org/forums/showpost.php?p=4617012&postcount=149).

Of course, these are all displays of the "summary" metrics, which are collected typically upon some periodic basis and obviously represent an overall summary of the I/O operation activity observed by hIOmon during that time period (and overall).

hIOmon can also be configured so that it captures an I/O operation trace of the "TRIM" control I/O operations. In this case, the captured I/O operation information will include the "Data Set Ranges (DSR)" specified by each individual TRIM control I/O operation.

A DSR identifies the starting offset (i.e., essentially the starting block/sector address for the particular set of blocks/sectors) along with the overall combined length of these blocks. A single TRIM control I/O operation can specify one or more DSRs.

So this technique can be used to explicitly identify the particular LBAs that have been requested by the TRIM control I/O operation(s) to be "trimmed".

[Ao1]

To compare here is a delete using the same 6GB file on an X25-M 160GB drive.

The TRIM command execution is also delayed by a couple of seconds after the file is deleted.

[johnw]

So, is your data saying TRIMing a 6GB file takes 0.02sec on an X25-M, and 5.9sec on a Vertex 2?

[Anvil]

johnw

That sounds about right.

Intel does nothing except for "releasing" the LBA when "trimming" the data, the SF controller does a lot more apparently.

I'll try to do the same on one of the V3's I've got, TRIM looks to behave differently on the SF-2XXX controllers.

--

edit:
@overthere

So how would deleting say 4000 files look like if the LBAs weren't contiguous, lets say there were 500 ranges?

[Ao1]

24TB. 88.

Ok this workload is much too light. All we are doing is sequentially writing to the SSD and slowly wearing out the NAND. 2TB per percent that I am seeing right now would mean 200TB to reach 1, or 5000 cycles on each NAND cell, which happens to exactly be the spec.

Anvil, how about adding some random writes, meaning, making changes within the generated files?

But won't the cache on your 320 turn the writes into sequential? Maybe that is why the F3 appeared so fast, as it has 32MB of onboard cache.

[Ao1]

John, I tried streaming with audio. Even if I use a Wave format (uncompressed) I can only get 1MB/s. Tracktor has a buffer so unless a large file was deleted whilst recording it would be unlikely to have an effect.

That said it is now clear that the SSD does not schedule TRIM during a low activity period. Whatever is running when it executes will become unresponsive for however long the TRIM command takes to execute. If you work with large files that might become a problem.

[Ao1]

Delta between most-worn and least-worn Flash blocks: 4
Wear out 99%
12TB

[johnw]

That said it is now clear that the SSD does not schedule TRIM during a low activity period. Whatever is running when it executes will become unresponsive for however long the TRIM command takes to execute. If you work with large files that might become a problem.

With the Vertex 2. On the X25-M, your data showed only a 0.02sec time for the TRIM, right? So probably not an issue with an Intel SSD.

[Vapor]

I wonder if the Vertex2 is taking the wear out value from the 'best' of the NAND? That is, SF wear leveling may be ineffective with this usage scenario and SandForce (or OCZ's firmware tweaks) may be taking the value from the NAND with the least wear.

Intel seems to be doing it with average wear (as was said, 1% per 2TB is right in line with 5000 write/erase cycles), or they have really effective wear leveling (maybe both?).

[Ao1]

With the Vertex 2. On the X25-M, your data showed only a 0.02sec time for the TRIM, right? So probably not an issue with an Intel SSD.

Not with the X25-M, but maybe the 320 is different.

EDIT; with the SF drive I think there is a clue as to what happens when TRIM is executed in that its the same for compressed or uncompressed data. I'm going to guess it's mostly due to the processor on the SSD, rather than the actual delete operation.

[johnw]

Not with the X25-M, but maybe the 320 is different.

Anything is possible, but I think the X25-M and 320 are very similar in most respects, including TRIM implementation.

[overthere]

@overthere

So how would deleting say 4000 files look like if the LBAs weren't contiguous, lets say there were 500 ranges?
That's a good question. :)

Unfortunately I do not know what particular algorithm(s) the filesystem would use under such circumstances. I could speculate, but I am loathe to do so - and least generally :)

There are, however, some empirical metrics captured by hIOmon that might provide some general clues perhaps - which BTW is intentional by design. ;)

For example, if you take a look at Ao1's post #69 (http://www.xtremesystems.org/forums/showpost.php?p=4855354&postcount=69), you will see a value of 1 for the "Control_MDSA_Trim_DSR_Count_IOP_Min" metric. This metric indicates the observed minimum total number of DSRs specified by a single TRIM control I/O operation (i.e., the combined total number of DSRs specified by a single TRIM I/O operation).

On the other hand, the "Control_MDSA_Trim_DSR_Count_IOP_Max" metric has a value of 62, which indicates that the maximum total number of DSRs specified by a single TRIM control I/O operation was 62 DSRs. (I seem to recall hearing that the ATA spec notes some option (?) about limiting the count to 64 or so, but I'm not sure about this).

From an overall perspective, the "Control_MDSA_Trim_DSR_Count" metric indicates that there was a combined total of 274 102 DSRs specified by the TRIM control I/O operations so far (the "IOPcount_Control_MDSA_Trim" metric - not shown - would indicate the actual total number of observed TRIM control I/O operations associated with this grand total of 274 102 DSRs).

One other quick note in regards to a single TRIM control I/O operation: The "Control_MDSA_Trim_DSR_Length_Total_IOP_Min" metric indicates the minimum total combined lengths (in bytes) of the DSRs specified by a single TRIM control I/O operation. The value shown in Ao1's post is 430 231 552 (which again reflects the minimum total number of bytes specified by a single TRIM control I/O operation).

The "Control_MDSA_Trim_DSR_Length_Total_IOP_Max" metric (not shown in Ao1's post) indicates the maximum total number of bytes specified by a single TRIM control I/O operation.

[Anvil]

@john
It should be very similar but there are a few new feature in the 320 series that could make a small difference.

Snipped from TechReport (http://techreport.com/articles.x/20653)
"The Intel 320 Series protects against any data loss that might occur in this situation by employing "surplus data arrays." Also referred to as XOR—the logical operation often used to calculate parity bits for RAID arrays—this redundancy scheme is capable of recovering data from a failed bit, block, or even an entire failed die. Intel describes XOR as a NAND-level RAID 4, making it sound rather similar to the RAISE technology employed by SandForce controllers.

RAISE is described as more of a RAID 5 than a RAID 4, though. SandForce says RAISE spreads redundancy data across the entire drive, and that the storage capacity lost amounts to the capacity of one flash die.
Intel isn't specific about the amount of storage consumed by XOR, but it does say the redundancy data is rolled into the 7% of total flash capacity reserved for use by the controller. According to Intel, XOR is governed by a mix of hardware and firmware that doesn't introduce any performance-sapping overhead. The only time it'll slow the drive down is when data is being recovered in the event of a flash failure."

So, redundancy without overhead?

[Anvil]

That's a good question. :)
...
On the other hand, the "Control_MDSA_Trim_DSR_Count_IOP_Max" metric has a value of 62, which indicates that the maximum total number of DSRs specified by a single TRIM control I/O operation was 62 DSRs. (I seem to recall hearing that the ATA spec notes some option (?) about limiting the count to 64 or so, but I'm not sure about this).
...


I've read somthing that resembels that limitation, there were/are some issues with the default Windows drivers behaviour that did/does not follow the specifications for TRIM commands, Intels driver does.

I'll have a look at the links.

I'll dive back into hIOmon as soon as possible, time to check what's new on the SF-2XXX controller and the new m4's on TRIM :)

[johnw]

So, redundancy without overhead?

Sure, like RAID 1, as long as you can write in parallel, it does not take any longer to write it multiple times. With RAID 4, you have to compute the parity, but that should be much quicker than the bottleneck of writing to flash, so again, redundancy without slowing down writes.

[Ao1]

Here is some data for a single TRIM loop. 11 seconds!

[Ao1]

and here is a shot after a few more loops. The offsets are ~the same.

[overthere]

FYI, the values shows in Ao1's hIOmon WMI Browser screenshots above for the "Control_MDSA_Trim_DSR_Length_Total_IOP_Min" and the "Control_MDSA_Trim_DSR_Length_Total_IOP_Max" metrics are transposed/reversed.

That is, the "Control_MDSA_Trim_DSR_Length_Total_IOP_Min" value shown is actually the "Control_MDSA_Trim_DSR_Length_Total_IOP_Max" value and the "Control_MDSA_Trim_DSR_Length_Total_IOP_Max" value is actually the value shown for the "Control_MDSA_Trim_DSR_Length_Total_IOP_Min" metric.

In other words, for example, the "Control_MDSA_Trim_DSR_Length_Total_IOP_Min" value in post #182 (http://www.xtremesystems.org/forums/showpost.php?p=4857628&postcount=182) should be shown as 18 588 976 and the "Control_MDSA_Trim_DSR_Length_Total_IOP_Max" value is actually 14 539 702 272.

This is due to a reporting defect in the hIOmon support for the hIOmon WMI Browser. The other means for reporting these metrics (e.g., the hIOmon CLI and the hIOmon Presentation Client) display these values correctly.

This reporting error has already been corrected in the upcoming new release of the hIOmon software. Sorry for any confusion. :(

[Computurd]

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.

woah...at what files size?? under normal usage?? and what is the latency of that access? 8-9 ms?



12TB.....Wear out 99%.

sorry, this leads me to believe that something is wrong with this testing regimen with this particular drive, or smart data is drastically wrong. there is no way it is truly that durable, they would market the living crap out of that. 12X+ the endurance of any other drive?
yea right. something is amiss.




EDIT; with the SF drive I think there is a clue as to what happens when TRIM is executed in that its the same for compressed or uncompressed data. I'm going to guess it's mostly due to the processor on the SSD, rather than the actual delete operation.

low powered processor deleting compressed data. has to uncompress, process, re-compress?

[Ao1]

Delta between most-worn and least-worn Flash blocks: 5
Approximate SSD life Remaining: 98%
Number of bytes written to SSD: 14080 GB

Seems wear is not linear.

[Computurd]

Seems wear is not linear.

interesting. 12 GB for a change of one percent, then 2 GB more for change of 1 more percent. I wonder how many GB for the next percentage point? weirdness.

[Anvil]

The wearout indicator isn't exact science, my drive started at 99% having 120GB Host writes and looks to be wearing more than 25nm NAND when one should think it was the opposite.

Ao1's drive also has about 4TB of easily compressible data written to it, MWI (SSD Life) started dropping after having performed a FW upgrade (could be an coincidence).

It's much to early to conclude anything yet :)

[bulanula]

It's much to early to conclude anything yet :)

Indeed. Just cannot wait to see how much abuse these drives will take !

Thanks !

[One_Hertz]

I can do that, although a lot of these writes are actually "random".

How are they random? Are you somehow telling the filesystem which clusters to place those files into? I didn't know you could do that.

26TB, 86%.

[Anvil]

It's not random in the IOmeter kind of way, working on it, you can expect something this week.

Starting to get re-allocations, up from 2 to 4 last 24hours and MWI is at 86.

114600

[Ao1]

How about reducing the "Min GB free" setting? Would that not increase the span being written to thereby inducing more wear? It might also be able to do it without slowing down writes in the process.

EDIT:

Delta between most-worn and least-worn Flash blocks: 6
Approximate SSD life Remaining: 97%
Number of bytes written to SSD: 15,936 GB

[Anvil]

I suggest we fill it up with more static data, leaving 22GB free space and then we change the min free space to 9 or 10GB.
(e.g. incompressible data like mp3's, mpeg or jpg's)

Whatever changes we do, seq. speed won't change, the only factor that can push the drive is by including more random writes.
I don't think I will personally introduce more random IO until 35TB is made and from then on introducing e.g. 500MB of random 4K writes per loop would probably do it.

I'm working on it, those things needs to be logged and then exported to e.g. Excel.

Here's the latest status on Media Wearout

114602

[Ao1]

Maybe we are just getting impatient :)

The main thing for me is that the workload is reasonably representative of what could be expected in real life.

Increasing static data will increase the amount of NAND that will never be used and reduce wear levelling. Writing full span over the space with no static data is also unrealistic. :shrug:

[Ao1]

Any questions or comments before I begin the test on May 24, 002011 @ 12noon EST?

Do we have takeoff? :)

[Anvil]

I'm not impatient :)
It's a slow process with my drive, much slower than yours :)

Some more static data wouldn't hurt though.
Too much random writes is whats unrealistic, desktop users don't do much random writes "the IOmeter way" at all.
The small files we are creating is what is normal "random" IO, the difference is that we are deleting them over and over again and so the LBAs are all "cleaned" for each loop.

The random part I'm thinking about including in the loop would never (never or very seldom) be deleted and that would put more strain on the process, too much would be unrealistic though so maybe 500MB is a bit to much, will have do do some math on it :)
Well, I've already had a brief look at it and on my drive 500MB per loop would mean about 85-90GB per day of random writes, that's quite a bit of random writes.
If the random write limit was 7.5TB it would mean 85 days and we've already used quite a bit of that reserve I'd expect.

Make no mistake, this is not going to be done in a few weeks, the site I originally linked to struggled for a year :), if we introduce a bit of random writes we might be done within a few months.

When I reach the 35TB limit (or so) I'll be moving it to a different computer (a home server) where it can just sit until it's done, having that extra computer is what makes this possible.

[One_Hertz]

During normal use some changes are made within existing files. We need to introduce a bit of this activity IMO...

[Anvil]

Yeah, I'll make it a setting where we can put any number of MBs we'd like, would be handy for making adjustments if the random IO part shows to be really effective.

[Ao1]

According to SSDLife I'm going to be running this for another 9 years. :rofl:

To be fair it has only just started monitoring, so it's probably not adjusted to the amount writes being incurred.

[Ao1]

Intel specs are 20GB per day for 5 years = 36,500GB
Assume 3,000GB per day with the endurance app.(post #4)
3,000GB = 150 days at 20GB a day.
In 1 day the drives are therefore incurring a 150 days of writes.
5 years = 1,825 days/ 150 = ~12 days.

In theory the chart should look like this.

[One_Hertz]

29TB. 85%. I got my first reallocated sector!

[Anvil]

24.41TB
4 Reallocated sectors, (and is it sectors or is it really a page)
Media Wearout is at 85

and FFFF (E2-E4) returned sometime last night, will have to run smartmontools to clear it up.

114616

[Metroid]

My drive matched Anvil's drive wear out level, One Herts's drive has written 5TB more at no wear out cost as it stands, Ao1's drive has surprised me by wearing out rapidly after a point. Th Sandforce drive seems interesting to look at.

[Ao1]

SSDLife reassesses the situation. :)

Delta between most-worn and least-worn Flash blocks: 7
Approximate SSD life Remaining: 96%
Number of bytes written to SSD: 18432 GB

[Ao1]

My drive matched Anvil's drive wear out level, One Herts's drive has written 5TB more at no wear out cost as it stands, Ao1's drive has surprised me by wearing out rapidly after a point. Th Sandforce drive seems interesting to look at.

Don't forget that the SF started off writing highly compressible data. 4TB or 5TB worth.

It will be interesting to see how linear the wear is with uncompressible data.

Is wear levelling with SF is 100% dependent on how compressible the data is?

Intel drives don't have that advantage, so they must rely on different techniques. The fact that the 320 is lasting longer (so far) than the X25-V with NAND that has ~40% less PE cycles is quite remarkable. It is able to write faster and last longer with less PE.

Assuming that the only wear levelling technique is compression the SF drive should start to rapidly deteriorate, but we will soon see. :)

I've been thinking about why read speeds get throttled with SF drives. My guess is that the channel that restricts write speeds deals with 2 way traffic. You can't slow down writes without slowing down reads at the same time.

"If" that is the case it is not that sophisticated, as there should be no reason to slow down read speeds.

Throttling read speeds and the poor implementation of TRIM seem to be the Achilles heel of an otherwise great technology.

It would be interesting to see what Intel could do with the SF controller.

[bulanula]

It would be interesting to see what Intel could do with the SF controller.

From the leaked Intel SSD roadmap slides we can expect to see an Intel SSD with SF controller pretty soon ( Q4 2011 ) !

http://thessdreview.com/latest-buzz/intel-ssd-roadmap-surfaces-depicting-520-cherryville-with-familiar-sandforce-capacities/

[Metroid]

Is wear levelling with SF is 100% dependent on how compressible the data is?

Unfortunately it is looking that way.


Assuming that the only wear levelling technique is compression the SF drive should start to rapidly deteriorate, but we will soon see. :)

I want to be wrong on this too but likely the deviation will not be too far out.


I've been thinking about why read speeds get throttled with SF drives. My guess is that the channel that restricts write speeds deals with 2 way traffic. You can't slow down writes without slowing down reads at the same time.

"If" that is the case it is not that sophisticated, as there should be no reason to slow down read speeds.

Throttling read speeds and the poor implementation of TRIM seem to be the Achilles heel of an otherwise great technology.


The constraint is quite understandable if it's compressed otherwise I say very poor software implementation. I think that even with compressed data read speeds should not have been affected but at the end the trade-offs and decision making favoured write speeds and that is what we see. Sandforce may have improved the Vertex 3 on this regard. We can't be sure unless we test it.


It would be interesting to see what Intel could do with the SF controller.

Not sure if Intel would do the same trade-off.

[Computurd]

The fact that the 320 is lasting longer (so far) than the X25-V with NAND that has ~40% less PE cycles is quite remarkable. It is able to write faster and last longer with less PE.

all 25nm devices will last longer than the previous gen counterparts. And the next generation will go even further. When i was speaking with the head of R&D for LSI we were discussing flash in general (started with a WarpDrive discussion). Right now his stance is that the market doesnt need to be doing any more shrinks, there are so many gains to be made with the current generation of nand. The place where the increases are by far the greatest is in controller technology, with the coupling of current gen tech, you could be looking at 50 percent more durability from the current gen of controllers. Kind of like the quad core v six core debate. why keep going further if you arent even using what you have?

no surprise that these controllers with 25nm nand are more durable than the previous generation. That is the whole purpose of this evolution of SSD. Alot of people are thinking the sky is falling with lower PE ratios, but the real true fact is that the situation is going the exact opposite direction. The endurance and durability and reliability is going upwards at a phenomenal rate. but of course that is what has been said all along, but there are always the chicken littles LOL
no coincidence that Intel is going with 25nm MLC for its next gen enterprise series. Not only has the performance jumped from the controller usage, but MLC in general is being managed in much better way, especially with revolutionary technology such as ClearNAND.
i will tell you this though, some industry insiders frown upon the transition from SLC to MLC, regardless of the maturation of the technology.

[Anvil]

My drive matched Anvil's drive wear out level, One Herts's drive has written 5TB more at no wear out cost as it stands, Ao1's drive has surprised me by wearing out rapidly after a point. Th Sandforce drive seems interesting to look at.

And your drive had been running 24/7 for about 1 year?
Mine has been running for 350+- hours, doesn't look like that matters even though this is a test and yours has been running "for real".



Is wear levelling with SF is 100% dependent on how compressible the data is?
...
Assuming that the only wear levelling technique is compression the SF drive should start to rapidly deteriorate, but we will soon see. :)
...


From what I've read, the SF controller doesn't tolerate high deltas on least/most worn "flash blocks", meaning that it starts shuffling static data when needed, don't know about other controllers, there may be some static wear-leveling but we'll probably never know.

Most data in real life are compressible, at least for the OS drive so one can easily add 30% or more to the final result of this test. (as long as it stays at incompressible data)
Testing with incompressible data is of course important but I it leaves a lot of questions to be answered.

As for Intel using the SF controller, at first I thought it was a bit far fetched but when the Marvell controller popped up in the 510 I didn't know what to think, so, IMHO, it's not impossible.
I do think for that to happen Intel probably would wan't to write their own firmware. (like Crucial did for the Marvell controller)
There are some "bugs" or side effects or what ever one wants to call it that would never have been tolerated had it been an Intel SSD.
Still, I really enjoy the SF drives, I've had the same level of maintenance with these drives as with other SSD's, nothing more nothing less.

There has been quite a few fw updates on the SF drives but personally I've never been waiting for some fix, that I know of.
There is that TRIM bug that never got fixed on the SF-1XXX series, that's about it.

@CT
Without the shrinking we would never get to 1TB 2.5" SSD's and prices would leave most people out in the cold.
There is of course some truth in that things are happening too fast, 20nm NAND was already on the table (at least in the headlines) before 25nm drives were available.

edit
updated graph in the post #1

[Computurd]

@CT
Without the shrinking we would never get to 1TB 2.5" SSD's and prices would leave most people out in the cold.
There is of course some truth in that things are happening too fast, 20nm NAND was already on the table (at least in the headlines) before 25nm drives were available.

yes, of course that is THE major driver. I guess we were speaking to performance/endurance more than anything. there is just so much left on the table. TBH the scaling on the controllers on the ssd themselves is actually not that great. they cant really handle the entire throughput of the nand at the end of each channel. of course this will be lessened somewhat with the newer generations, simply because of fewer channels.

EDIT: this does create an interesting situation with certain models of ssd, say the maxiops..a new gen controller strapped on 'old' nand that has higher PE ratio...since it is optimized and much more efficient (for use with 25nm) shouldnt the maxiops line have some really awesome endurance?

[Ao1]

As for Intel using the SF controller,


I'm sure Intel would use their own fw as they did with the 510 Marvell controller. The time Intel take to test would mean it would either be an older SF controller or a specially developed controller for Intel.

I've been impressed with the SF drive. I would have liked to play with it a bit before destroying it. :ROTF: For sure though a bit of Intel finesse would not hurt to slick things up.

Anyway back on topic, I have emailed you an excel sheet with a few more stats thrown in. Just a thought, no worries if you don't want to use it.

[One_Hertz]

They need to keep shrinking to get costs down. The speeds are more than enough for most users. The endurance is more than enough for most users. The price is way too high for most users.

31TB/85% as of 6 hours ago. I just picked up my 320GB mlc iodrive so I will be playing with that soon :cool:

[Anvil]

I just picked up my 320GB mlc iodrive so I will be playing with that soon :cool:

:shocked:
I guess the price was right :)

@Ao1
Will have a look in an hour or so, preparing something for you right now :)

[One_Hertz]

:shocked:
I guess the price was right :)

Only $1300USD!

Are we changing the amount of static data and free space? I am quickly approaching 35TB.

[Anvil]

I'll send you the new version where random data is part of the loop. (within 10 minutes)
I'm just making the last few checks.

We just need to agree on the runtime length (it's configured in ms)
I think that's all we need to do for now, it adds by default a 1GB file for random writes.

[Anvil]

25.72TB host writes

No changes to MWI

114623

edit:

+ chart updated...

[Ao1]

Delta between most-worn and least-worn Flash blocks: 8
Approximate SSD life Remaining: 95%
Number of bytes written to SSD: 21,376 GB

[Anvil]

27.06TB Host Writes
Media Wear Out 84%

Re-allocated sectors unchanged (4)

[One_Hertz]

35TB. 82%. Still 1 reallocated sector. I will switch the software to the new version this evening.

[Ao1]

Delta between most-worn and least-worn Flash blocks: 9
Approximate SSD life Remaining: 94%
Number of bytes written to SSD: 22,272 GB

EDIT: Guys are you making a switch at 35TB? What settings?

[alfaunits]

Just got the time to look at the file randomness. Anvil, can you run a CPU benchmark of whatever generates that random file?
That's the reason I asked for it, it looks like a hash of random bits rather than random bits.

The reason I ask is if this can't do something like 500MB/s for generation, and it's done in the same thread as the writing, you are essentially doing sequential transfers mostly :( (the overall "write" speed would be an indicator)
Regardless of how random the file is (compression-wise) or your internal file I/O, it seems the overall I/O is mostly sequential.

Though I am not sure I understand any more what you guys are trying to achieve, but with such small random I/O, it is hardly real-world.

[MadHacker]

actualy to save on CPU usage so that there is no lag, all random data should be pregenerated.

[Anvil]

Regardless of how random the file is (compression-wise) or your internal file I/O, it seems the overall I/O is mostly sequential.


In what regard?
Not sure that I follow.



Though I am not sure I understand any more what you guys are trying to
achieve, but with such small random I/O, it is hardly real-world.

There isn't much random IO in real life but there is some and thats why we are adding a small portion of random I/O. (on top of small file I/O)



actualy to save on CPU usage so that there is no lag, all random data should be pregenerated.

I have 3 alternating buffers so It's generally not an issue.
1.5GB/s was what I measured using a small array on the Areca 1880.

[alfaunits]

In what regard?
Not sure that I follow.
Well, let's say (just for the explanation) that your random generator can produce 100MB/s. X25-M can also do 100MB/s of sequential.
As a result, since (if I understood you correctly) they are done in the same thread, without backbuffering, the resuling write speed would be 50MB/s.
If you get that overall speed, then X25-M is writing sequential data and not random I/O.


I have 3 alternating buffers so It's generally not an issue.
1.5GB/s was what I measured using a small array on the Areca 1880.

It looks like you generate the random data in a separate thread then, so I misunderstood. I don't see how the entire system (as in the CPU/memory/PCI-e even) would be able to sustain those speeds.

[Ao1]

What happens past the write instruction issued at the device level? Will the SSD controller not try to fill a complete block whenever possible to minimise read/ relocate/ write penalties?

Presumably it would try to avoid 4K writes being scattered across the span of the drive. Isn't that what Intel refer to ask write combining?

Would it also try to rotate locations of writes for wear levelling?

Just asking as I don't really know :up:

[Anvil]

@alfaunits
Whether the random data generator is producing 10MB/s or 100MB/s has nothing to do with writing randomly or not.

The Areca can sustain those speeds until the cache is filled or as long as the array can sustain that speed, I was using a small array incapable of coping with that speed and thus it wasn't sustained. (it lasted for a few seconds)
The easy test is just to generate the random data without writing the data, that would tell the potential of the random "generator".

Anyways this is out of topic, a separate thread would be needed and I haven't got the time right now.

@Ao1
We can only presume but that's the general idea of write combining.
If the file spanned the whole drive everything would be random per say, what we have been doing so far is just producing writes (both small and large files) but no random IO within those files.
Random writes withiin a file overwrites data in stead of just writing a new file, there is a huge difference between those two scenarios.

edit
Link to Anand (http://www.anandtech.com/show/2829/5)

[Ao1]

From what I've read, the SF controller doesn't tolerate high deltas on least/most worn "flash blocks", meaning that it starts shuffling static data when needed, don't know about other controllers, there may be some static wear-leveling but we'll probably never know.

I didn't think that any of the G2 drives could do static data rotation, although I have heard talk of it. For sure the X25-M can't do it, maybe the 320 can however.

12GB of data on the SF drive has only been written to once. If that 12GB of NAND could be swapped as the rest wears down it would extend the life quite a bit.

Without static data rotation the MWI will get to 0, but there will still be 12GB of unscathed NAND. That is a likely real life scenario as well.

[Anvil]

I think the Intel (and most others) do static data rotation, I can't see how it would work if they didn't.

SandForce static data rotation (http://www.ocztechnologyforum.com/forum/showthread.php?75773-Secure-Erase-TRIM-and-anything-else-Sandforce&p=553183&viewfull=1#post553183)

It does require idle periods though :)

[alfaunits]

@alfaunits
Whether the random data generator is producing 10MB/s or 100MB/s has nothing to do with writing randomly or not.
If you are doing it in the same thread as the actual writing it does, because the writing needs to wait on the generator.


The Areca can sustain those speeds until the cache is filled or as long as the array can sustain that speed, I was using a small array incapable of coping with that speed and thus it wasn't sustained. (it lasted for a few seconds)
The easy test is just to generate the random data without writing the data, that would tell the potential of the random "generator".
I did not even take Areca into consideration here, but just the bare CPU, memory and PCI-e link. If you do it in the same thread and you can send 1.5GB/s to Areca (does not matter what Areca does with it, it can ditch them even), that means the combined speed of generator and PCI-e link is over 6GB/s total (3GB/s each on average, so per second they can write at half of the average = 1.5GB/s). You have to agree that's... too much?
Are you generating the random bits in the same thread that does the writes, or is there a separate thread for them in the background? (I suggested a back thread already, you said you have no time, so I presume it's all done in the same thread).
I know you have "grr" mind reading my posts, but I am not trying to play smart - if the above numbers and thread assumption are correct, something is too fishy and the entire test is skewed.

[Anvil]

Why are you always making assumptions, loaded with negativity?
(that's how I'm reading most of them unfortunately, I may be alone in making this conclusion, I don't know?)

To answer some of your "questions"
1.5GB/ was using threads
The Endurance test is not using multiple "threads"
The random data is currently being pregenerated using 3 buffers...

Now, can we continoue this thread, which is about Endurance testing, not about making assumptions :)

[alfaunits]

Because I question illogical things. I want to know if you're doing a useful thing here or just wasting several SSDs with sequential transfers. And I know I'm not alone in that questioning.
GNU RNGs can barely do tens of MB/s, hardware RNGs don't do >500MB/s, so yes I am quite suspicious of the claim that without threads you get RNG performance that is fast enough compared to SSD speed to think it does not affect the overall "write" speed, i.e. not making this just sequential transfers overall.

To make a test, you have to assume it's valid. This looks invalid. But it's your money dumped on an SSD. If you do reach close to 200TB for the 40GB X25-M you'll just prove me right here :(

And if I am completely wrong, my sincere apologies. I don't pick random fights with people who have something to learn from, and you are one of them. Please consider it constructive criticism or my learnign curve.

[Anvil]

I don't think you've been reading this thread.

The random generator test I did on the Areca wasn't being generated real-time, I never claimed it was, it's pregenerated.
The test on the Areca has nothing to do with this test, it was in a completely different manner but still using the same pregenerated formula.

If you are a programmer, write yourself a simple function that looks like this.

declare a buffer of 4MB and fill the buffer using

for I = low to high do
buffer[I] = random(255)

Write the buffer to a file, it will be incompressible.

The data written to the Intels are just filled with "garbage" from the stack, they don't do compression so why spend cpu power on them.
The speeds so far at writing is at the staggering rate of 30-50MB/s.
This is so simple that I can't believe you are questioning the test, it could have been done using a simple batch file just copying files and getting the same results.

Well, it's all there, it can be monitored using any tool.

[Anvil]

29.2TB Host writes

Media wear out 83

114655

[Ao1]

Delta between most-worn and least-worn Flash blocks: 10
Approximate SSD life Remaining: 93
Number of bytes written to SSD: 24,704 GB

Later I will remove the static data, let the app run for a bit and then I will put the static data back on. That should ensure that blocks are rotated.

[Ao1]

The mother of all TRIMs. 20 seconds. That is based on no static data running Anvils app with only 1GB free....so it's a delete for the full span of the drive.

Now I will put back the static data and let it run normally. Hopefully this will help slow down the delta between most-worn and least-worn flash blocks.

[alfaunits]

Sorry then. I was under the impression all of them used random data, which is why I disliked the outlook. I did notice 0Fill for your Intel test, just forgot.


I don't think you've been reading this thread.

The random generator test I did on the Areca wasn't being generated real-time, I never claimed it was, it's pregenerated.
The test on the Areca has nothing to do with this test, it was in a completely different manner but still using the same pregenerated formula.

If you are a programmer, write yourself a simple function that looks like this.

declare a buffer of 4MB and fill the buffer using

for I = low to high do
buffer[I] = random(255)

Write the buffer to a file, it will be incompressible.

The data written to the Intels are just filled with "garbage" from the stack, they don't do compression so why spend cpu power on them.
The speeds so far at writing is at the staggering rate of 30-50MB/s.
This is so simple that I can't believe you are questioning the test, it could have been done using a simple batch file just copying files and getting the same results.

Well, it's all there, it can be monitored using any tool.

[Ao1]

I had to guess a few of the inputs (especially for one_hertz) but even if you take out the highly compressed data the SF drive worked with for the first ~5TB it is still doing really well so far, especially considering data is now uncompressible with no let up for static data rotation.

MWI = wear out/
R/Sect = relocated sectors

[Ao1]

Here are a couple of charts that show the impact of throttling based on file size and level of compressibility of data.

Obviously this is worst case thottled state, but both sequential read and write speeds are hit quite hard with uncompressible data. Highly compressible data on the other hand is unaffected.

[Anvil]

Those are very nice charts Ao1

The SF compression chart is just like I figured it would be :), quite interesting as the drive is being throttled as well.

[One_Hertz]

80%, 2 reallocated sectors, 37.5TB. Switching to the new software.

[Ao1]

Intel have posted a link to a very interesting white paper:

www.usenix.org/event/hotstorage10/tech/full_papers/Mohan.pdf

It talks about the impact of the frequency of writes.

Longer recovery periods between writes can significantly boost endurance, allowing blocks to potentially undergo several millions of P/E cycles before reaching the endurance limit.:eek2:

(Its not going to happen in our test) ;)

[Anvil]

80%, 2 reallocated sectors, 37.5TB. Switching to the new software.

We didn't agree on the random part, it's set to 1000ms per loop by default.

1000ms = 20-30MB? on the Intel's, is that something we can agree on or do we wan't more?

--

I've finally reached 30TB + :)

30.18TB Host writes
Media Wear out 82
Re-Allocations still at 4

@Ao1
Interesting link, will do some reading.

[Ao1]

Here is some more info :)

P/E specs are based on the minimum.

http://www.jedec.org/sites/default/files/docs/JESD47H-01.pdf

[Ao1]

Delta between most-worn and least-worn Flash blocks: 11
Approximate SSD life Remaining: 92%
Number of bytes written to SSD: 26,432 GB

[bulanula]

Really nice to see Intel g3 with 25nm nand beat g2 with 34nm nand! !

[Ao1]

Delta between most-worn and least-worn Flash blocks: 12
Approximate SSD life Remaining: 91%
Number of bytes written to SSD: 28,352 GB

Edit:

Another interesting snipet from the Intel forum:

"Read disturb refers to the property of Nand that the more a block of Nand is read, the more errors are introduced. A brief note about Read Disturb (and other various Nand properties) are discussed in this technical note from Micron:

http://download.micron.com/pdf/technotes/nand/tn2917.pdf


Static data that is read frequently will eventually need to be refreshed or relocated before it reaches the Read Disturb limit because of this Read Disturb property."

[Anvil]

A lot of good reading in all those links!

32.02TB host writes (just seconds ago)
MWI 81

nothing else has changed.

114673

[Ao1]

I had to reboot to apply Window updates and now it seems that DuraClass has really kicked in on uncompressible data. :mad:

I tried a secure erase from the OCZ toolbox, but it has not helped. When I tried to copy the static data back (mp3's) I could only get around 10MB/s. (Ended up at 8.55MB/s)

The endurance app is currently running at 4.13MB/s :shakes:

Dang, looks like its game over for me unless I can get the MB's back up.

[Anvil]

I'd let it idle a while. (a few hours)

Pretty strange that it didn't slow down until the reboot?

I also had a reboot today (had been running for 12days ++ without rebooting) and the speed picked up the first initial loops, not much, will check a bit later.

[Ao1]

It might have occured when the app stopped running or it might have been the reboot. Currently the app is running at 6.52MB/s.

I'm going to do another secure erase, but then I will only run the app with no static data.

If that does not work I will leave it on idle.

[Anvil]

Sounds like an idea.

If it needs idling it could take days, interesting turn anyways. If full throttling means ~10MB/s it's pretty much "disabled".