Printable View
Probably Intel SSDs only, please share if other SSDs have it.
Well, I thought I didn't do much writing when I plugged the X25-M into my laptop. But it only "acquired" some 100-200GB of writes in the last 2-3 months in which I am sure I have copied VMs back and forth so much that just the copy surely incurred a TB of writes.
If you've even noticed the Host Writes on your SSD, what is its value and do you find it is true?
This is a 30GB X25-E. Being used as a boot disk for about a year. Page file enabled.
http://hostthenpost.org/uploads/a728...0832bda7c0.jpg
This is an 40GB X25-V. A bit older than a year old. Used on a media server as a boot drive. Page file enabled.
http://hostthenpost.org/uploads/49ff...89c2ac731a.jpg
I'd really like to see the host writes on my X25-M G1, it would be through the roof as it is has been in heavy use for a good 2 years now.
My G2 that was used in my first rig (sig below) for about a year as boot drive has been moved to the 2nd rig, wiped and new OS installed.
CDI shows Host Writes is 3.02TB. Health is still 100%.
BTW - OCZ Vertex does not store / show Host Writes.
My X25-Es do have quite high use count compared to my X25-Ms, which I am sure are used more now.
Now I'm even more suspicious this particular X25-M/160GB is not recording all the writes. Used about 10 months in a laptop with heavy VM use and only 2.25TB of writes. Wearout at 98 though so the values work out correctly.
Man, that X25-V really was used and abused ;) More than 10GB a day.
CrystalDiskInfo can't read a Samsung SSD.
http://i55.tinypic.com/724pko.jpg
The funny thing is I don't use the system. It all it does is run my PVR software and usenet programs. I have started using FancyCache recently to cache the writes, so hopefully it sees some decrease in writes or at least I know the writes will all be sequential instead of random.Quote:
Originally Posted by alfaunits
The E drive is at least a year older and used to be the C drive. E drive now is more or less static data only.
From the Intelฎ Solid-State Drive 320 Series Enterprise Server/Storage Application Product Specification Addendum
http://www.intel.com/design/flash/na...ldocuments.htm
Example Calculation of Drive Wear
The following is an example of how the drive wear attributes can be used to evaluate
the impact of a given workload. The Host Writes S.M.A.R.T. attribute (E1h) can also be
used to calculate the amount of data written by the host during the workload by
reading this attribute before and after running the workload. This example assumes
that the steps shown in Section 3.4 were followed to obtain the following attribute
values:
• Timed Workload Media Wear (E2h) has a raw value of 16. Therefore, the
percentage wear = 16/1024 = 0.016%.
• Timed Workload Host Read/Write Ratio (E3h) has a normalized value of 80,
indicating that 80% of operations were reads.
• Workload Timer (E4h) has a raw value of 500. Therefore the workload ran for 500
minutes.
• Host Writes Count (E1h) had a raw value of 100,000 prior to running the workload
and a value of 130,000 at the end of the workload. Therefore the number of sectors
written by the host during the workload was 30,000 * 65,535 = 1,966,050,000
sectors or 1,966,050,000 * 512/1,000,000,000 = 1,007 GB.
The following conclusions can be made for this example:
• The workload took 500 minutes to complete with 80% reads and 20% writes.
• A total of 1,007 GB of data was written to the device, which increased the media
wear in the drive by 0.016%.
• At this point in time, this workload is causing a wear rate of 0.016% for every
500 minutes, or 0.00192%/hour.
Dedicated 24/7 to WCG.
I played around with Hard Disk Sentinel today. A couple of interesting things.
On their web site they state "Current SSD technology also has another problem: solid state disks may "forget" data with time. To prevent this, periodic complete overwrites can refresh the storage device...."
Hmm, not heard that before, although it sounds feasible.
On my E drive I have static data only. In theory over time I should see write activity occurring. Not sure how that could be monitored as presumably it's an internal SSD command.
Next up its seems that using "sleep" puts loads of writes on the drive. I thought sleep, as opposed to hibernate, did not dump loads of data to the drive. :shrug:
On the right hand side below is just before a sleep. On the left straight after the sleep. I noticed that the SATA light is full on before the PC shuts down, so its defiantly writing, but did it write ~1GB of data or 10MB? I'd guess 1GB by the SATA light activity, but hopefully not. Dang, I use sleep all the time.
By the way max xfer rate - ~60MB/s. Whoop.
That program is that Ao1?
Hi lowfat, Hard Disk Sentinel
http://www.hdsentinel.com/
Looks like I'm winning on GB written per hour :)
Attachment 114228
It's the boot drive on a computer running a few Windows Servers on VMWare.
(on other drives obviously)
Metroid/ lowfat I guess you know you are running on old f/w? The latest is 2CV102M3:
"This firmware revision fixes enumeration and slow-boot issues on SATA 6Gb/s controllers, adds improvements to S.M.A.R.T. attributes for more accurate reporting of drive health, improves NCQ capability, and fixes possible drive hangs when reading S.M.A.R.T. self-test log."
Anvil = 0.06GB/h
mezcal = 0.21GB/h
ender17 = 0.21GB/h
bot@xs Vertex = 0.56GB/h
lowfat X25-V: = 0.79GB/h
Ao1 C = 0.88GB/h
lowfat X25-E: = 0.90BG/h
Ao1 E = 0.92GB/h
bot@xs X25-M = 1.20GB/h
Metroid = 2.62GB/h
My old G1.
Did duty in several boxes earlier in its life but has been serving as a boot drive in a dedicated wcg box for about a year now.
The BOINC data folder is on the other drive or I imagine the writes would look much like Metroids.
I set it up that way 'cause I was concerned that BOINC and the lack of TRIM would bring the G1 to it's knees in short order.
Whether that was a justifiable concern or just me being paranoid I really don't know. :shrug:
I was too lazy to update that. The Supercomputer week is over now. So I may find 5 minutes to do that. That may improve my host writes. :rolleyes:Quote:
Originally Posted by Ao1
Ops. It looks like my dedicated WCG drive is leading it. The Clean Energy Project - Phase 2 tortures it all. :rofl:Quote:
Originally Posted by Ao1
I am honestly surprised your drive hasn't died yet. AFAIK those are nearly on the brink of what Intel says their 40GB drives should do in terms of writes.Quote:
Originally Posted by Metroid
I think those figures are for random writes, while actual endurance is higher. 7.5/15/30TB for random writes for 40/80/160 IIRC? And something like 36/72/144 max. life span.
Die in the sense of not writing any more to the drive and only reading then yes.Quote:
Originally Posted by lowfat
I really want to find this out, 16GB is for the Windows 7 64 bits. So 21GB is the wear space. So 21 x 1000 = 21000TB.Quote:
Originally Posted by alfaunits
Attachment 114231 Attachment 114232
should i be concerned
Either my drive is not recording the writes or you guys are bashing the drives with benchmarks ;) I can't believe I only did 2.25TB in 9 months - I know I did over 300GB in a day a few times.
EDIT: Eh :( CDI says 17 days of total use - the laptop was not turned off for months since August (just rebooted for updated and that's it). Meh ;)
C300s report good power on hours. Cool I can sell this X25-M as new now :D
lol yeah right :) god only knows the writes on my devices, scared to look!:eek2:
The X25-V specs are 5 years(min) with up to 20GB of host writes per day. (Typical workload).Quote:
Originally Posted by lowfat
2.62GB/h * 24 = 62.88GB per day.
9341 hours = 390 days.
~ three years worth of writes in one year. Wear out only 15%. Not bad at all for a 40GB drive with only half the channels of a larger drive. :cool:
I don't bench that much, but I do use sleep all the time. 4 to 6 times a day typically. At 1GB a pop that is racking up the writes. It would be good if I could work out a way to deflect those writes onto a HDD. I don't care how long it would take as I've walked away from the PC by that stage. I imagine hibernation would be even worse for generating writes, especially if you have 8/ 12 GB's of RAM.Quote:
Originally Posted by alfaunits
Not at all. Interesting however that the Vertex appears to be wearing out much faster than the Intel drive.Quote:
Originally Posted by bot@xs
9.5TB on my iodrive but it doesn't show power on hours. Considering Fusionio claims it lasts through 44PB, I am only 0.02% through the writes on this thing :ROTF:
Concerned, no. Update the firmware on the LE? Yes.Quote:
Originally Posted by bot@xs
The X25-E 32GB does 1PB of random writes, havent seen any figures for mixed I/O.Quote:
Originally Posted by One_Hertz
I've been planning on doing a durability test on one of my SSDs but a few months back I found one test that's been going on for over 1 year.
So far that X25-V has written close to 1PB, I'll post a link later today.
How is that possible? With flawless wear leveling that would imply that all the cells were rewritten 25,000 times, which is well above spec for cheap MLC flash.Quote:
Originally Posted by Anvil
I always wanted to do a test on an X25-M. Throw it on iometer and give it a mixed sequential/random different block size write test. Record when it fails.
I don't know
Heres one of the links, there is another page thats more recent but the link is on my laptop.
(on my IPad now)
Here is the last link (you need to translate somehow :))
Each cell is written 24641 times according to the text on that page. (haven't checked though)
904600.41GB in 7224 hours would be ~125GB/h or ~35MB/s. (sounds high on average)
Attachment 114245
That is just ridiculous. How in the eff is that SSD still going?
There is no way that is legit. If it was, Intel would be singing praises about the longevity of their SSDs instead of claiming they can withstand just 15TB of random writes.
Perhaps this is why. Not sure if % are based on the number of operations or the volume of data, though.Quote:
10 ~ 100KB 80% (System thumbnails and the like)
100 ~ 500KB accounted for 10% (JPG images and the like)
5% 1 ~ 5MB (big picture, MP3 and the like)
5% 5 ~ 45MB (video clips and the like)
full span writes. which write @ much slower speeds, and since there is no free space on the drive, there is not as much power for wear leveling, write combing, etc. it is a WORST case scenario. a random write on a 100 percent full drive cannot function 'normally'.Quote:
15TB of random writes.
(7500000000000 / (300 * 4096)) / 60) / 60 = ?
(7500000000000 / 1228800) / 3600 = ?
(6103515.625 / 3600) = 1695.42 Hours
OR 70.64 days of completely random IOs. (full span write ONLY)
Off by a little before cause I used 4k vs 4096. The specification has random write I/Os at 300/s using a full span.
The intel addendum lists their measured IOPs at 300 for 4k full span QD=32 random.
When you do limited span IO testing (say 8gb testfile) you get increased efficiency of coalescing and caching mechanisms resulting in increased performance. This is why the iops for smaller datasizes is much more, to the tune of 30 mb/s if i recall correctly.
If you are getting >10x the write speed then you are also getting at least 10x the coalescing. If they are getting 10x the coalescing then they are getting 10x the endurance.
An increase in spare area from 7% to 17% provides over a 2x increase in write endurance. This is directly from Intel. 10% spare area = 280% improvement in write endurance under most circumstances.
Think if he is using the drive basically empty.
EDIT: also you must realize it is Host writes. after write combining and the effects of NCQ from the OS there can be a tremendous difference between host and OS writes.
Most likely. One of my projects will be done in a month or so then I will switch to CEP2. I really want to see how much this SSD can withstand.Quote:
Originally Posted by Computurd
File size/ sequential vs random make a huge difference to the burn out rate. If you want to calculate a particular load and project how long the SSD will last based on that particular load Intel explain how to do it. See post 7, which is explained a bit more in one of the IDF 2011 papers: Solid-State Drives (SSD) in the Enterprise: Myths and Realities - Session SSDS003
https://intel.wingateweb.com/bj11/sc...talog.jsp?sy=0
Yes, that explains part of it, but not to the extent of writing 1PB to an X25-v. Here Intel claims the 160GB X25-M can withstand 150TB if only 96GB is used and the rest is left for overprovisioning (8.3k 8KB random write IOPS in this config or 66MB/s):Quote:
Originally Posted by Computurd
http://cache-www.intel.com/cd/00/00/...555_459555.pdf
X25-V has 4x less NAND so we are looking at 37.5TB. That asian site is claiming to have written 25x that amount already and that the SSD is still 97% healthy. There is no way. I am near willing to buy and kill an x25-v to see for myself.
What if the SMART data is wrong about the life?
The drive might be healthy, but the wear out indicator is on 1. No relocated sectors though, which seems a bit strange. I read somewhere from Intel that even when the indicator drops to 1 you will still be able to carry on writing for some time.Quote:
Originally Posted by One_Hertz
The test methodology is hard to follow when translated. It seems that most writes were sequential and consisted of relatively large xfer sizes. It also seems they stopped the test every 12 hours to run the toolbox.
One of the other links Anvil provided seems to look at the impact of endurance without TRIM. It's too hard for me to follow what they are saying, but it would interesting to know.
I guess it can only provide an indication, but I would imagine Intel did a lot of research both on understanding typical workloads and then testing the NAND until it burnt out under those loads before they put the product out to market.Quote:
Originally Posted by RyderOCZ
For sure Intel are very robust in their endurance claims.
There are AA (170) retired blocks on that thing and is has been increasing a lot lately.
A pity it would take a year to reproduce, unless it failes within a few months.
I dont think theres anything wrong with this test, it's just not clear what's been done, the only thing we "know" is that host writes are 2-5 times higher than one can expect from 34nm NAND.
Writing 36.5"TB" (20GBx365days*5years) should be doable in a couple of weeks :)
http://www.pceva.com.cn/html/2011/st...319/229_2.html
Here is a bit of info on Sandforce performance throttling to kerb P-E cycles. In option E you can factory set the throttling. I wonder which option reviewers get.
Hope so!Quote:
Originally Posted by Ao1
But after their P67-B2 fiasco I wouldn't blindly trust them. ;)
again, all of intels endurance testing specs are with full span. no write combining, wear leveling or GC. absolute worst case scenario.Quote:
ere Intel claims the 160GB X25-M can withstand 150TB if only 96GB is used and the rest is left for overprovisioning
yup. 25x the amount of a full span test. should be easy actually if you are benefitting from teh write combining and the wear leveling and the GC. and if they're doing the toolbox every 12 hours, walk in the park.Quote:
That asian site is claiming to have written 25x that amount already and that the SSD is still 97% healthy
see, lets think here. what would write amplification be without ANY write combining? do you think it would be 10 times worse? or 100 times worse? whats your thoughts on that?
QOTD: What percentage would wear amplification be if there was no benefit of write combining?
you can get 280 percent endurance increase just from OP. even more is possible. and that is measured, again, with full span writes.
dont trust the smart data. im sure the wear is much worse than that.
EDIT: if the intels only took that much writing, that quickly, they would be dying in droves by now. I am on tons of storage forums, and nowhere have i seen anyone pop up and say "ive written my drive to death" for any type of SSD, let alone the Intels.
@Ao1
Lots of info on that site :)
@CT
If you look at the CDI info.
E9 = Media Wearout Indicator, and it's 1, they start off at 100 and so I believe that Ryder (OCZ) could be right, the 97% Health status can't be trusted in this case.
(SMART isn't quite there yet)
yea smart is pretty lame tbh. i have yet to see of one predicting correctly when the ssd will be written to death. which would be hard to do anyways, i havent seen any :) *yet*
Did you not read the link? They use 96GB out of 160GB. 64GB is available to do all the write combining SSD needs to do. That test is not full span. Full span implies the full 160GB is used.Quote:
Originally Posted by Computurd
You don't seem to understand why what they are claiming is impossible. Even if what they are doing is absolutely the easiest workload imaginable for the Intel SSD (it isn't) and the write amplification is 1 (can't get below 1, unless compression is used which Intel does not do), then they claim to have overwritten each cell 25,000 times. This is 5 times more than the spec for 34nm MLC flash. No matter how magical you believe the controller to be, it can not do anything to increase the raw life of the NAND which is being used. The absolute best the controller can do is not waste any write cycles on unnecessary operations.
If the flash cells could withstand 25,000 writes and still operate, the manufacturers sure as hell would not be marketing it at 5k.
well yes, when they are testing the benefits of OP. maybe i did word that incorrectly, but regardless, pointing out a minor flaw in a large post that lists many facts is not going to dissuade me from the fact that your reasoning is flawed.Quote:
They use 96GB out of 160GB. 64GB is available to do all the write combining SSD needs to do. That test is not full span. Full span implies the full 160GB is used.
where are all the mass die-offs?
how many guys have quite literally obliterated vertex gen 1's with thousands of pointless benchmarks, not to mention daily usage that is extreme, and their devices are fine, A-OK. I know i have :)
where are these people with all of these dead drives?
have you considered the fact that manufacturers are intentionally setting the bar very low, as they quite simply dont know for sure?
at the end of the day, endurance testing is for one thing: showing the absolute worst case scenario. we all know how drives that are at 100 percent capacity perform like crap. the reason they do is because they are essentially not able to perform their 'housekeeping' correctly. it is the worst case scneario for any device, but in practical application there just isnt any real world data that would point to a empty disk degrading to a point of uselessness as quick as a disk that is absolutely 100 percent full.
there isnt any mass die-offs or mass complaints to evidence the fact that these drives can only handle that much random writing in normal usage scenarios. we hang out on forums man. on most forums that is where people come to complain and whine. i swear some forums out there are just a bunch of people :banana::banana::banana::banana::banana:ing about products incessantly. every little thing.
believe me we would be the first to know if these isssues were out there.
Who said there is an issue? Most people are writing sub 10TB to their SSDs... there is no problem if the limit is 30-40TB (and much larger for larger SSDs). 30-40TB is A LOT of benchmarking. More than what anyone does. I was merely saying that an x25-v can not withstand 1PB of writes. It is impossible. Nothing more nothing less.
Actually, Intel's handling of their mistake makes me trust Intel more. That sort of problem probably would not have been discovered by consumers or reviewers for a long time -- it probably would have been months before the SATA ports started failing. But Intel discovered their own mistake, and voluntarily recalled all the bad parts. Obviously it would have been better if the mistake was not made in the first place, but given that the mistake was made, I cannot see how Intel could have handled it any better.Quote:
Originally Posted by zalbard
I've never seen the definition for the 5K specification. Anyone know the details?Quote:
Originally Posted by One_Hertz
For example, if the lifetime is 5K P/E cycles, what does that mean statistically? Perhaps they test 1TB worth of cells, and after 5K cycles, 99.99% of the cells are okay? Or maybe at double the cycles (10K), 90% are still going? There must be some statistical definition for the 5K cycles spec. I would assume the probability of failure after 5K cycles would be very low, but if that is the case, it may be that 95% of the cells may last much longer than 5K. If there are enough reserve cells in the SSD, then you could replace 5% and keep going.
So I am surprised if a 34nm flash SSD has written enough for 25K P/E cycles. But I would not dismiss it as impossible. It really depends on the details of that 5K specification.
Regarding the X25-V, Intel says:
http://download.intel.com/design/fla...hts/322736.pdf
So 365 x 5 x 20 = 36.5TB
The key word there is "minimum". What is being measured is more like maximum, or at least typical maximum.
endurance is not a predetermined moment in time guys. thats a big point here. it is when the unrecoverable bit errors pass a certain pre-defined threshold. but that threshold itself is not a finite moment. it depends upon the quality of ECC, etc.
here is a document you MUST read seriously it opened my eyes big time. Once you read this you will realize that their definition of endurance is WAY below the usable threshold of the drive.
from idf 2011 a few months back\
Solid-State Drives (SSD) in the Enterprise: Myths and Realities
it is session SSDS003. read the PDF please i beg you :) A01 linked it above, but no one read it apparently. :p:
https://intel.wingateweb.com/bj11/sc...og.jsp?sy=8550
endurance is defined as:
http://i517.photobucket.com/albums/u...e1/arguing.png
That is presentation is about endurance at the SSD level. The 5K P/E spec is at a lower level, that of the flash integrated circuits.
correct. but we are discussing endurance of the SSD here. as a whole. the nand is only as good as the controller, so for those too lazy to read i will put up a few shots here.
First: they arent testing the drive correctly. the key parameter here is retention of data for a long period of time. not sure how well this device is retaining data at this point. so the test is a fun test, but not accurate.
Second: You must understand that the endurance numbers for Intel SSDs are extreme worst case scenarios. they bake the freaking drive for gods sake, then test retention. as i keep saying over and over, extreme worst case scenario.
http://i517.photobucket.com/albums/u...1/arguing2.png
http://i517.photobucket.com/albums/u...1/arguing5.png
im on a rant here, so follow along :)
here we show that increasing the LBA range does in fact hamper the performance of the drive, and reduce endurance. so that is why these drives can take a tremendous amount more than they are marketed as.
and the one below it is the bathtub curve of paranoia. fits this topic perfectly imo.
overall we are looking at 3 percent failure of the device at extreme circumstances in order to fall below the threshold of endurance. which is ridiculously high standards. the drives can survive long long long after that, and be usable. especially for us normal people LOL
http://i517.photobucket.com/albums/u...1/arguing4.png
http://i517.photobucket.com/albums/u...1/arguing3.png
There is no "correct" way to test a drive. It depends on what you are testing. I think it is reasonable to test by writing to the drive until it starts giving write errors. At that point, it would also be interesting to test whether all the data can be read back, and to let it sit for a while and test again. But just testing how much you can write is a reasonable test.Quote:
Originally Posted by Computurd
As for baking the drives, I think you misunderstand the test. They bake the drives to do accelerated lifetime testing. The basic idea is that you come up with a formula that says, say, 400 hours at 85C is equivalent to 30,000 hours at room temperature. That is how they can spec values at 5 years when the prototype is only a few months old. It does NOT mean that Intel is saying that the parts can work for 5 years at the elevated temperature.
i understand the process. much like they test many many other devices.Quote:
They bake the drives to do accelerated lifetime testing.
im not inferring that they are spec'ing the drive at those temps. they have their own temp specs rated.
the point is this: they are doing accelerated writes in a very small amount of time (worst case scenario again) and doing it under extreme conditions that 99 percent of the drives will never see.
note: also they do non-accelerated room temp testing. they cover both bases here.
yes this would be the most interesting, because that is the root cause of nand death...it cant hold the electron anymore...but if it can hold it short periods of time thats easy, but with gate degradation that is where the ability to maintain long term retention should become comprimised, at least initially. that would be the beggining stages i would imagine.extended torture write testing, then baking, then non accelerated room temp testing, THEN doing a bit error test after extended rest time-- should just about do it and catch the error rate under pretty much any scenario.Quote:
At that point, it would also be interesting to test whether all the data can be read back, and to let it sit for a while and test again.
It would be nice to know the overall size of the file. If it was quite small and only wrote to a small span of the drive then effectivly the rest of the drive was OP - which could explain it. :shrug:
Regarding that health status on CDM I have no idea how that it calculated. If the drive is functioning correctly (no errors) does that make it healthy? The wear out indictor is working, but just because the drive is close to the end of its life does that make it unhealthy?
Hard to tell but it looks like the largest that test file could have been was ~280MB
• 100KB 80% 10 ~ 100KB 80% (System thumbnails and the like)
• 500KB 10%100 ~ 500KB accounted for 10% (JPG images and the like)
• 5MB 5% 5% 1 ~ 5MB (big picture, MP3 and the like)
• 45MB 5% 5% 5 ~ 45MB (video clips and the like)
5 x 45MB = 225MB
1 x 5MB = 5MB
100 x 500KB = 48.82
10 x 100KB = 0.97
Total = 279.79MB
Agreed. All companies make mistakes. The distinction is how companies fix those mistakes. The only complaint I would make against Intel is the lack of TRIM support for G1 drives, other than that its hard to fault them. (In fairness they never said TRIM would be provided, but it was petty minded not to).Quote:
Originally Posted by johnw
Also a big difference between a geniune mistake and a deliberate deception.
I've got a spare X25-V (Kingston) and I'm seriously thinking of doing such a test.Quote:
Originally Posted by One_Hertz
It's been used for a few benchmarks only, < 100GB written.
If you performed a random test I can do a sequential one :p:
Hi Anvil,
Intel think they can reproduce the experiment and are willing to try. They are open to suggestions from XS on how to run the experiment.
http://communities.intel.com/message/124701#124701
interesting the link to the other test, where another person is almost at a PB! i would chalk this up to intels being very conservative in estimates, the extreme low tolerance for failure in testing, and the conditions of the testing. very interesting nonetheless! makes me feel safer about write testing already :)
http://botchyworld.iinaa.net/ssd_x25v.htm
I'm in. Since I will be buying a new SSD to do this, will it make more sense to buy a different brand so perhaps we can do a comparison between them to see which fails first? Unfortunately I don't think we can do Sandforce because it is my understanding that it will throttle writes down to nothing and won't let me kill it... Perhaps a small M4?Quote:
Originally Posted by Anvil
Thats great One_Hertz :)
I'll have to check on the m4, there is probably an issue wrt retrieving "Host Writes" on both the C300 and the m4. (WD doesn't support/report host writes either)
The SandForce and Intels are both supporting this and some report both host read and host writes.
There is probably a way to circumvent the SF throttling issue but it would require cleaning the drive at least once a week. (only takes a few seconds using the toolbox)
I cannot guarantee that the cleaning would work though.
I'll check the Crucials and let you know...
It is the same test, its just on different sites. (same serial# on the SSD)Quote:
Originally Posted by Computurd
Sounds good. I am not sure we can entirely get around the SF write throttling... I could get an Intel 320 40GB for just ~100$ right now. A 64GB M4 would be ~150$.Quote:
Originally Posted by Anvil
We do not NEED to have the SMART info giving us the writes. If it is done via IOMeter, then IOMeter will provide us with the amount of writes (unless the whole system decides to crash upon SSD failure, which may happen).
It would be interesting to see an X-25V (34nm) vs a 320 (23nm).
How will you run the test? With static data? How large a test file overall? What size files? Random vs sequential? TRIM/ no TRIM?
I've checked and there are some metrics on both the C300 and the m4 that are of use
05 - Reallocated sectors count
AA - Growing Failing Block Count
AD - Wear Levelling Count
BB - Reported Uncorrectable Erors
BD - Factory Bad Block Count
C4 - Reallocation Event Count
C5 - Current Pending Sector Count
CA - Percentage Of The Rated Liftime Used
These are reported by the CDI 4.0 Alpha. (if the naming is correct)
Host writes arent reported and it doesn't look like it can be calculated using known/official methods?
The Intel 320 would be great as it's a 25nm drive.
As you say, there are other methods of recording Host Writes but SMART would be the better option.
I'm working on a storage benchmark/utility and I could easily integrate both reporting and the actual process of generating the writes, logged to another drive :)
This is the readout using the latest CDI Alpha
Attachment 114311
Attachment 114313
edit
@Ao1
Not sure yet about how but thats open for discussion :)
I just ordered a 40GB 320.
The test file should be about 75% of the size of the SSD? That seems realistic to me. Nobody keeps their SSD empty, but nobody has theirs full either. It should be some sort of mix of various blocks sizes with emphasis on 4k... mix of random and sequential.
Ao1 - you had logged 2 weeks of activity at some point using hiomon. Where is this info again?
Without checking log files I'd have a guess at something like this:
- 4K 80%/ 80% sequential/ 20% random
- 8K 10%/ 50% sequential/ 50% random
- 1k 2% /Random
- 1MB 3% /Sequential.
- 3MB 2.5% / Sequential
- 6MB 2.5% / Sequential
Maybe 50% static data and a total file size of 25%?
Sandisk wrote an article about this http://www.sandisk.com/media/65675/LDE_White_Paper.pdf
Quote:
One statistic of interest is the distribution of request size of the writes, which is as
shown in Figure 2a for our sample user trace. Note that over 53% of the writes are for 8
sectors (4KB); 8.9% are for 128 sectors (64KB), 5.7% are for 16 sectors (8KB), and
4.9% are for 32 sectors (16KB). However, note that 16.7% are not multiples of 4KB.
Why would they reference a trace from a non 4K aware OS (XP) using a HDD with only 1GB of RAM? :shrug:
Nice info though. :up: I see they say 29% of all write commands are sequential.
Everyone's going to have a different workload. At least this one is documented. Just a shame it was on an antiquated set up.
Well, I've had fancycache statistics menu running for about six hours, it has tracked roughly 3GB of total writes, which works out to 12GB a day. With fancycache write cache, writes to disk are cut down to almost half(~6.76GB/day,) which means an X25-V would last ~15 years with my usage and setup.Quote:
Originally Posted by Metroid
I thought would be better than that but still good. I will do some tests in the coming month. Thanks for the info :)Quote:
Originally Posted by keiths
The setup doesn't matter in determining these numbers... the data written would be the same on HDD or SSD. The low RAM could increase certain writes however.Quote:
Originally Posted by Ao1
Ehh, I was wondering why it showed I/O >4KB which is not 4KB aligned.
Quote:
Originally Posted by Ao1
160GB G2 used in my main machine since launch
all user folders are mapped to RAID0 hard drive array
http://i.imgur.com/Z46nl.png
Agreed but it suggests the PC being monitored was more or less being used as a type writer. It would have been much better if they used a trace from a modern PC/ OS with a wider range of applications. Using an SSD for the trace would also have been more helpful.Quote:
Originally Posted by One_Hertz
At the end of the day however it is still going to be mostly small xfers, but maybe some larger xfers would have shown up.
No it would not, and considerably. NTFS journaling and MFT access on a larger HDD drive is different than on an SSD.Quote:
Originally Posted by One_Hertz
No? Expand?Quote:
Originally Posted by alfaunits
One_Hertz
ETA for your drive?
Today apparently. NCIX is very fast here in Canada.Quote:
Originally Posted by Anvil
I guess we need to come to a consensus on our test parameters so we do the same thing. Are we going to TRIM the drive or not? Some users will use TRIM, others will not due to RAID or due to an OS that doesn't support TRIM.
The whitepaper I linked recommends using QD 1 for endurance testing as higher QD is not necessarily realistic (as Ao1's testing showed as well).
For size distributions maybe 50% static data, 25% test file size, 25% empty? What mix of block sizes do you want to use? As for seq/random I am thinking 70% random?
Are we using IOMeter or are you writing us a utility?
So we have a 320 & an X25-v head to head? :cool:
My vote is for TRIM.
For comparison here are the JDEC xfer sizes for their proposed SSD Enterprise Endurance Workload.
That doesn't seem too far off the mark to what I have seen when monitoring, although I do see larger xfers ~ 1MB and above from time to time. Larger xfers are obviously more application centric, whereas those below are more OS related. I'd vote for a bit of a mix.
512 bytes (0.5k) 4%
1024 bytes (1k) 1%
1536 bytes (1.5k) 1%
2048 bytes (2k) 1%
2560 bytes (2.5k) 1%
3072 bytes (3k) 1%
3584 bytes (3.5k) 1%
4096 bytes (4k) 67%
8192 bytes (8k) 10%
16,384 bytes (16k) 7%
32,768 bytes (32k) 3%
65,536 bytes (64k) 3%
http://www.jedec.org/standards-documents/docs/jesd219
This test will take forever. Such a workload will be very very slow at QD1 on these 40GB SSDs. 10MB/s? I guess we'll see.
There are a lot of things to take into consideration but I'm sure we'll find some middle ground.
We can't really recreate normal operations and so the question is what do we want to find out?
First of all, should we do the same test or should we take different routes?
Is there a point in doing the same test?, it would of course tell us what we can expect using 25nm vs 34nm NAND.
Keep in mind that this is a very small sample size :), a different batch of NAND could perform better or worse.
50% static is too much imho, ~12GB would be sufficient. (about the same size as the W7 OS)
So, I suggest using:
-12.5-15 GB of static data
-A single 2.5GB "static" random datafile for random writes. (TRIM wouldn't work on the random datafile as it wouldn't be deleted/recreated)
-12.5-15 GB for creating/deleting or copying files
That would leave 25% of the drive empty.
No over-provisioning, just the standard op set from factory.
The most realistic route would be to dynamically create/delete files and I do think we need to make the use of TRIM.
Then there is the matter of reporting/collecting data, there are several ways to report and publish, either manually or by that utility I'm creating.
I can put a "screenshot" of the collected metrics on an FTP server and we could just link it to that new thread. A lot of options, could be updated every hour or whatever we decide on.
I haven't decided what computer to run the test on yet :), I've got a couple of options though.
I suggest we settle for something and run it for a few days just to see what happens and then we make adjustments based on what happens during that "test" period.
We could be in for a surprise, I don't know what to expect... :)
I think we should do the same test... if we do a different test and see different results then we won't know whether it is due to NAND differences or the different test.
What software do you propose we use for this? I've got an old crappy P4 rig I can throw W7 onto and run 24/7 for this test.
OK, then we go for doing the same test.
W7 would be perfect, I'll see what computer I can find, might be a laptop but that shouldn't make a difference.
I'll PM you some more info on my utility later tonight and we'll take it from there.
We'll just have to make sure that we're able to somehow retrieve SMART info from the SSDs/disk controllers, it might work form my utility, not sure yet.
edit:
It shouldn't be a problem using the filesizes that Ao1 suggested, 4K writes QD1 are at 35-40MB/s on a fresh X25-V, could change dramatically within a few hours though.
As part of the test we could also copy/delete files from the Windows directory over and over again.
We need a way to automate everything... copying/deleting files by hand is not an option at all.Quote:
Originally Posted by Anvil
Sure.
We'll just need some way to monitor that it's still working and for reporting, so, a bit depending on how we can get to that SMART info it should be fully automatic, including reporting.
i think that using the Jedec standards would be great. looks to be very exciting, cant wait to see this test :)
The MFT reserved area is smaller on an SSD than on an HDD of a similar size, thus more of an SSD is used, whereas on an HDD certain are of the drive (10% even) might never be touched unless the drive gets filled >90%.Quote:
Originally Posted by One_Hertz
The log does not record last access time on an SSD by default, whereas it does on an HDD (W7 only).
The area where data is written to on an SSD is different than that on an HDD because the starting format is not the same. There is quite a bit of difference. It's not 50% or probably not even 20% difference in terms of amount, but with random I/O it can be >10%.
I still don't know what you mean, but yes I forgot the W7 SSD optimizations.Quote:
Originally Posted by alfaunits
I mean the data written is not the same, in reply to "The setup doesn't matter in determining these numbers" - the setup does matter.
You guys up and running yet?
If not could you run the test file for a hour first and then use Intel's method to calculate the projected wear rate based on SMART values?
This could then be compared to what happens as the experiment continues.
The worst possible endurance scenario for the 40GB 320 is 5TB, which could be racked up in 3 days @ 20MB/s 24/7. Once speeds slow down to a crawl maybe it would last a couple of months.
I can see this lasting at least 6 months, maybe a year even.
Yeah, we're up and running.
I started a bit ahead of One_Hertz, his 25nm 320 looks to be a bit faster than my 34nm.
I'll start a new thread shortly.
It could take some time :), but, E9 "Wear-out" has already moved down a few notches on my drive, don't know about One_Hertz yet.