I think that is correct, since the threshold is clearly labeled as 10 in the SMART attributes. With SMART attributes, a failure is defined as the normalized value reaching the threshold value.Quote:
Originally Posted by Vapor
Printable View
I think that is correct, since the threshold is clearly labeled as 10 in the SMART attributes. With SMART attributes, a failure is defined as the normalized value reaching the threshold value.Quote:
Originally Posted by Vapor
This will be my last update at 100%. I will be switching to 46% after this post.
585.77 hours
209.7130 TiB written
40.72 MB/s
MD5 ok
05: 0
B1: 119
E7: 10%
E9: 170816
EA/F1: 215808
F2: 384
Any news testing an SLC drive ?
I restarted the process on both SSD's an hour ago, no specific reason I just wanted to get ahead of the SF drive doing it's disappearance act. (It had been running for about 33 hours without any issues)
Kingston SSDNow 40GB (X25-V)
345.41TB Host writes
Reallocated sectors : 8
MD5 OK
35.43MiB/s on avg (~1 hour)
--
Corsair Force 3 120GB
01 94/50 (Raw read error rate)
05 2 (Retired Block count)
B1 35 (Wear range delta)
E6 100 (Life curve status)
E7 88 (SSD Life left)
E9 56554 (Raw writes)
F1 75376 (Host writes)
107.62MiB/s on avg (~1 hours)
Uptime 216 hours. (power on hours)
SSDLife estimates lifetime to be 1 month 17 days. (November 13th)
M225->Vertex Turbo 64GB Update:
371.99 TiB (411.69 TB) total :D Another one past the 400 TB mark.
1054.44 hours
7922 Raw Wear
118.41 MB/s avg for the last 64.09 hours (on W7 x64)
MD5 OK
C4-Erase Failure Block Count (Realloc Sectors) from 4 to 6.
(Bank 6/Block 2406; Bank 3/Block 3925; Bank 0/Block 1766; Bank 0/Block 829; Bank 4/Block 3191; Bank 7/Block 937)
Attachment 120533
The SF drive was disconnected when I got home, so, it ran for about 1 hour after restarting the app.
Looks like a proper disconnect is needed not just restarting the app.
After the crash early last night, it looks like it crashed again probably somewhere around 4am or 5am. The really annoying thing is, the system crashes and reboots, but the BIOS can't find the OS, so it just sits at a black screen with the error message until I get there to to physically turn it off/on again. After a soft reboot it still can't find the OS, so I have to physically turn the system off.
I was running it with 5 min GiB free space, so maybe it's hanging on the delete section. I was kinda trying to get that to happen, but only while I was sitting in front of the system.
The last time I checked before the overnight crash it had crept up to a little over 124MBs. I'm still really liking this drive. OWC makes a 240GB version of this drive but it uses the 2282 SF controller, and is probably the fastest drive out there at the moment.
I stopped testing for a while, and while the drive was idling just after a reboot, I noticed that Raw Read Error Rate is probably just a timer. It increases at the same pace while idling as it does under endurance loads. If you open CrystalDiskInfo and then just continually refresh the info with F5 you'll see it tick up every second.
m4 update:
Here is the last screenshot before the avg restarted the rig and I lost contact with it.
538.0406 TiB
1759 hours
Avg speed 91.11 MiB/s.
AD gone from 46 to 42.
P/E 9430.
MD5 OK.
Still no reallocated sectors
Attachment 120551Attachment 120552Attachment 120553
I have restartet ASU and will bring next update tomorrow evening.
Kingston:
I'm gone try a SE and put the SSD on the esata controll to see if the problem goes away.
Creeping up on 600TB and 10k P/E cycle and still no reallocated sectors...amazing :clap:Quote:
Originally Posted by B.A.T
Mushkin Chronos Deluxe 60
05 0
Retired Block Count
B1 17
Wear Range Delta
F1 47754
Host Writes
E9 36770
NAND Writes
E6 100
Life Curve
E7 83
Life Left
Average 124.87MBs.
118 Hours Work Time
12GiB Minimum Free Space
SSDlife expects 21 days to 0 MWI
Attachment 120554
With that new firmware, the M4 is really the best thing going at 64 and 128 capacities, but the fact than not a single a sector has been reallocated is maybe more impressive. I hope the Mushkin keeps up (still holding steady at 0, but it's real early in the game...). But doesn't the Force 3 have the exact same NAND in it? It's already got two reallocations.Quote:
Originally Posted by bluestang
EDIT
I called Mushkin to try and order another drive and they told me they're completely sold out and that they won't have any more drives out there for another couple weeks. I guess it isn't just me out here singing their praises. Of course, Mushkin/Patriot/OWC/FutureStorageUK/EdgeTech are using the same American assembly facilities making the same drives, so it might be hard to fill all the demand.
My guess is it has to do with burn-in procedures. It is possible to run some tests on the flash after the circuit board of the SSD is assembled, identify marginal blocks, and mark them failed. I'm pretty sure Samsung does something like this on the 470 SSDs, since SMART attribute 178 started at 72 (instead of 99 or 100) and then held steady at 72 until near the end of the SSD's lifetime (when it began rapidly decreasing). I think this indicates that a number of flash blocks equal to about 28% of the reserve count were failed before the SSD was shipped, with the result that all the other flash blocks were tested to be very robust.Quote:
Originally Posted by Christopher
Judging from the behavior of the m4, I'd guess that Micron did something similar with a burn-in test.
But maybe some of the other SSD brands do not fail the marginal flash blocks during burn-in. So some other models may have reallocated "sectors" sooner than SSDs that do fail the marginal blocks during burn-in.
Maybe the Micron *AAA and AAB flash (sync vs async) are just graded and binned in such a way that all of the premium flash is just 50% more awesome. That, or SMART doesn't reflect some reallocations, or initial bad blocks get zero'd out. If it turns out that the M4 really just doesn't have any bad blocks after all these writes, then Crucial deserves some sort of official award -- I know my perception of 25nm flash has certainly changed based on it's performance.
Christopher, have you been able to figure out why your system is having BSOD?
Does your drive have the latest firmware? Try to figure out what version number of SandForce's firmware equates to that version of Mushkin's firmware.
It's 3.20 FW, which should be the latest SandForce standard FW revision.Quote:
Originally Posted by SynbiosVyse
To be fair, I've not actually "seen" a BSOD. I just walk away for a while, come back, and the system has restarted... but not back to Windows, as the OS can't be found by the BIOS. I'm not sure whether it would actually cause a BSOD or the system would just spontaneously restart. I'm confident that it has nothing do with anything but some kind of massive TRIM induced lock up. Maybe I'll actually be sitting in front of the system the next time it happens, but I've upped the Min GiB free to 12, so we'll see if it makes a difference.
Another thing to consider is that sometimes the drive feels quite warm... so if it feels warm outside, it might be sizzling hot inside. Maybe the controller is overheating?
Based on what I was able to gather from the first time this happened, from looking at the numbers, it seemed that it happened just at the end of the loop. Unfortunately, the ASU running totals don't seem to update during the loops, but only after you quit ASU, so if it hangs you'll lose the totals back to the program launch. If the numbers updated durning the loop it might help to pin down when it occurs.
Factory shipped defects in NAND are perfectly normal and are not an issue as long as they are within certain parameters. With IMF NAND I believe an invalid block is one that contains one or more bad bits. Out of 4,096 blocks at least 3,936 must be available throughout the endurance life of the product. [Speculation; maybe that is why the MWI appears so conservative] Invalid blocks are identified following worst case condition testing in the factory and are marked 00h, which enables a bad block table to be created so that the controller can avoid using them.
I understand that it's normal, which is why I'm wondering whether Intel and Micron (possibly others) either have 1) some process to zero out factory identified bad blocks in SMART data OR 2) really good NAND processes that just generate 100% good blocks (or a process to effectively bin NAND). Only my Indilinx drives have bad blocks now, and that's because they came from the factory like that, and so I have to wonder which scenario it is.Quote:
Originally Posted by Ao1
I'm pretty sure it is (1), as I explained previously (except I don't think Intel does it, at least not the the extent that Samsung and Micron do). Assuming you are talking about the SSD level, and not the bare flash level. As I said in my previous post, I think it is done after the SSD circuit board has been assembled.Quote:
Originally Posted by Christopher
I guess Ao1 didn't see my post.
Yes, but the Samsung's factory reallocation was evident in the SMART data. The M4 doesn't have any, so that's still impressive whether factory bad block invalidations are invisible to smart data or not... its still awesome.Quote:
Originally Posted by johnw
It is a rather arbitrary choice whether to include factory failed/reallocated blocks in the initial SMART attribute values. Samsung apparently chose to include it. Perhaps Micron chose not to.Quote:
Originally Posted by Christopher
I don't think it is necessarily "awesome" compared to the other SSDs. It is likely they have similar quality of flash, but some have just chosen to fail the marginal blocks early, and others have chosen to let the marginal blocks be used until they fail, which they tend to do earlier than the other blocks. Either way, the longevity of the SSD is primarily determined by the longevity of the vast majority of the flash blocks, not by a small number of marginal blocks that may or may not be counted as reallocated sectors during the early part of the SSD's lifetime.
Micron does have it as a SMART value. "Factory Bad Block Count" is present in the C300 and m4. It's a seemingly static number.
Aha! I see it, attribute 189. Thanks for pointing that out!Quote:
Originally Posted by Vapor
Cool.Quote:
Originally Posted by Vapor
I was looking for some CDI posts for the Microns. I gave away my M4 to a family member, so I don't have one to look at anymore.
So how many factory bad blocks did the Microns have? I don't remember seeing the full smart info, but I'm going to look back and see if it was posted.
Just for the record, is it irrelevant that a drive hasn't reallocated any flash after 1/2 a PB?
I don't think so, but I guess it's a matter of opinion. I just take that to mean that whatever flash wasn't factory flagged bad is really consistent.
Yes, so do I. The problem comes in when you say that the m4 is awesome because it has no reallocated sectors, while some other SSD is not so good because it does have reallocated sectors. That is a conclusion drawn from insufficient information. Most likely, the m4 had all of the marginal blocks failed at the factory, while the other SSD may not have gone through as stringent a test for bad blocks at the factory (or any test at all). Without knowing that, you are comparing apples and oranges.Quote:
Originally Posted by Christopher