Taking a Hard Look At SSD Write Endurance
New submitter jyujin writes "Ever wonder how long your SSD will last? It's funny how bad people are at estimating just how long '100,000 writes' are going to take when spread over a device that spans several thousand of those blocks over several gigabytes of memory. It obviously gets far worse with newer flash memory that is able to withstand a whopping million writes per cell. So yeah, let's crunch some numbers and fix that misconception. Spoiler: even at the maximum SATA 3.0 link speeds, you'd still find yourself waiting several months or even years for that SSD to start dying on you."
100000 writes? 1M writes?
What the fuck is this submitter smoking?
Newer NAND flash can sustain maybe 3000 writes per cell, and if it's TLC NAND, maybe 500 to 1000 writes.
I've done the math and always come out with years of expected use.
Each time I've tried an SSD it's failed after a year.
Now I use spinning platters. Cheaper, cooler, seem to last for ever. I miss the speed, but I need my disks to last longer than a year. I've got 10 year old 40GB disks still running fine.
100,000 is only for SLC NAND. MLC, what is currently in most SSDs, is only 3,000, and TLC (found in usb drives, samsung 840, and probably more SSDs soon because it's cheaper) is only 1,000.
Is 1,000 fine for most people, yes.. but you should be aware of it. I have a fileserver that writes 200gb per day.. which would kill a Samsung 840 in about 6-7 months.
http://www.anandtech.com/show/6459/samsung-ssd-840-testing-the-endurance-of-tlc-nand
>It's funny how bad people are at estimating just how long '100,000 writes'
>It obviously gets far worse with newer flash memory that is able to withstand a whopping million writes per cell.
So TFA claims that 100,000 is a bigger number than 1,000,000!? The author got the 2 numbers mixed up as new FLASH cells have 100,000 or less erase/write cycles vs the old 1 million.
Some phones use an internal flash chip partition as swap, I always wonder about the lifetime of these devices.
But if your SSD is nearly full with data that you never change, wouldn't all the writing happen in the small area that is left? This would significantly reduce lifetime.
Our company experienced what we believe was its first age-related failure in October of 2012, an office PC with an Intel SSD drive in the value oriented line of 2008 (which was still high at the time). Basically the drive behaved as a mechanical drive would behave with an occasional bad sector and we were able to successfully image the data to a new one. Out of 200 Intel drives, that's pretty good. (We did have one failure in 2010 but that was an outright dead drive and we were able to RMA it). Not sure if this contributes anything to the conversation but I figured I'd throw this out there.
The Intel X25's in my PC, from 2009, are still humming along nicely and my last benchmark produced the same results in 2012 as they did in 2010. But I've gone so far as to set environment variables for user temp files to a mechanical drive, internet temp files to a RAM drive and system temp files to a RAM drive, offsetting the wear leveling.
Which technology is Amazon using for their AWS instances? Their instance description page (http://aws.amazon.com/ec2/instance-types/) doesn't say one way or the other.
"It obviously gets far worse" is referring to "how bad people are at estimating", not the lifespan of the Flash Memory.
+1 IDisagreeSoHeMustBeATrollOrAnAstroturferOrAShill
I have never had a laptop hard drive last more than two years, and only had one last more than eighteen months. Maybe your spinning-metal-one-micron-away-from-the-drive-head drives work well in a stationary, temperature-controlled environment, I guess.
I know people like you. Their laptops never last, their screens are always splattered and often cracked, their iPods and ear buds are always breaking, their power cords are always twisted and frayed.
But my stuff lasts for years. My present laptop, a Dell Precision, is dated 2007. It's been all over the world, in filthy closets, big server rooms, up radio towers, on boats... I'd like to get a new one. But, I can't justify the replacement because my present laptop is in MINT condition save for the battery. Mint.
Some people take care of their stuff, many people don't.
meaningful life specs are tough to come by for flash. Yes, as noted above, SLC NAND has a rated life of 100k erases/page on the datasheet, but that's really a guaranteed spec under all rated conditions, so in reality, it lasts quite a bit longer. If you were to write the same page once a second, you'd use it up in a bit more than a day.
However, in real life, the "failure" criteria is when a page written with a test pattern doesn't read back as "erased" in a single readback. Simple enough, except that flash has transient read errors: that is, you can read a page, get an error, read the exact same page again and not get the error. Eventually, it does return the same thing every time, but that's longer than the "first error".
There's also a very strong non-linear temperature dependence on life. Both in terms of cycles and just in terms of remembering the contents. Get the package above 85C and it tends to lose its contents (I realize that the typical SSD won't be hot enough that the package gets to 85C, although, consider the SSD in a ToughBook in Iraq at 45C air temp..)
In actual life, with actual flash devices on a breadboard in the lab at "room temperature", I've cycled SLC NAND for well over a million cycles (hit it 10-20 times a second for days) without failure. This sort of behavior makes it difficult to design meaningful wear leveling (for all I know, different pages age differently) and life specs, without going to a conservative 100k/page uniform standard, which, in practice, grossly understates the actual life.
What you really need to do is buy a couple drives and beat the heck out of them with *realistic* usage patterns.
Almost certainly MLC. SLC is really only found in industrial SSDs these days. Enterprise and consumer SSDs are all MLC, with the exception of Samsung 840, the first SSD to use TLC.
In fact file systems need superblocks and they can't just evenly distribute everything across the platter. The superblock is obviously the first to go, so you'd need to cope with that by having various possible locations for it. Where do you store the location? In a superduperblock? How long does that last? Where do you store data on how many writes have hit each block? How many times do you overwrite that?
After all this basic housekeeping, maybe, you can spread everything else across the platter.
This calculation is best-case start to finish. Drives are not written with perfect evenness - that would be very very hard if not impossible to achieve. So you need actual figures for how well this can be done in practice. Any conclusions you make without that empirical data are likely to be overstated.
Does anyone know whether the failure count for cells picks up along a nice smooth curve or is like running into a cliff? Intel seem to be suggesting in their spec sheets that the 20% over-provisioning on some of their SSDs (I'm assuming for bad-block remapping when failure is detected) can increase the expected write volume of a drive by substantial amounts:
http://www.intel.co.uk/content/www/us/en/solid-state-drives/solid-state-drives-710-series.html
This seems to go against the anecdotal evidence of sudden total SSD failures being attributed to cell wear - something else must be failing in those, most likely the normal expected allotment of mis-manufactured units.
So basically, my data crunching app, running on an Android tablet (Transformer Infinity), with 64 GB of flash, running full tilt continuously updating. Will die very very quickly. I haven't measure the volume of updates, but it will be 20mbps or more.
I think that's about 8-9 months before I start seeing failures.
Oh well, I'm upgrading it to a 2Mb tablet soon, I'll hold the data all in RAM and only write out a daily backup. No big deal holding it in RAM since the tablet has a battery and seems rock solid.
Well *unless* Slashdot announces RAM dies after 100,000 writes...
If after buying the SSD it will take months, even years before it dies, I guess that there's no problem, eh?
BULLSHIT.
Story should have been entitled "Taking a Solid Look At SSD Write Endurance".
Badabing! I'll be here all week.
Better known as 318230.
This chart is almost 2 years old now, but it is a fun read and has some good testing information:
http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm
I have read that some of the newer SSD have only 500-1000 P/E cycles (eg. Kingston V300, Samsung 840), but I don't have proof. It is well documented that most of the current MLC drives have 3000 to 5000 P/E cycles while may of the SLC units are 100000 (eg. Intel X25-E, SuperSSpeed SLC S301).
Here is another good article about TLC SSD:
http://www.anandtech.com/show/6459/samsung-ssd-840-testing-the-endurance-of-tlc-nand
You have to buy and use the correct type of SSD for your application. A new TLC SSD should not be used in any write intensive application (eg. ZFS ZIL) but it may be great for that new fast laptop that can use the speed and does not do a lot of writes to disk. For most standard uses a good SSD will outlast the laptop/desktop where it is installed. The key for good SSD use is detection of pre-failure (SMART is a good start). The SSD is now a consumable part, just like the battery or brakes on a car. We all know drives fail, but standard hard drives don't have the same fixed life expectancy as an SSD.
Don't forget about Write Amplification. It can help kill a drive faster than total bytes written:
http://en.wikipedia.org/wiki/Write_amplification
SSD here has been rejected on multiple and continuous failure rates. Now it only gets given to end users who provide a 'light' write environment - and thats the only place where consumer level 25 and sub level nm write cycle gear can be used sanely (ie, without having a plan for swap out/replacement and higher costs).
I'm expecting a fairly severe level of failure on new equipment shipping today that uses SSD as cache.
I frankly love the speed. But the claims about how long an 'average' user would take to wear out these disks has failed with abysmal rate failures where I work. Admittedly, our users are mid to heavy use cases, but the failure rates have been high, and the life time shorter than anyone would contemplate.
Either the cost of the drives has to fall (which to be fair - it has been), or the reliability question and write limits needs to change substantially.
I no longer consider SSD for front line heavy use. And I'd need serious work to be convinced on contemplating it again with lower nm flash. And SLC level gear is simply beyond the cost level we can attain.
We`re all equal
There's a really handy post with actual data on this compiled by some people at the xtremesystems forum. It's nicer than this theory stuff, they've tested most consumer level drives available and literally written them to death to see how far they go. Still not perfect (some of the drives are different sizes, with different amounts of "static" data) but it's good for a ballpark anyway.
http://www.xtremesystems.org/forums/showthread.php?271063-SSD-Write-Endurance-25nm-Vs-34nm
I'm on the heavier end of the normal computer user and I still have a Vertex 1 drive still alive and kicking.
Seriously, if I'm going to pay $185 for a 256 GB SSD (and that's a GREAT sale - they're usually more), I wish the thing would last longer than that. An internal 7200 RPM 3 TB HDD sounds like a better choice!
Newer technology needs to be introduced that can be written to tens of millions of times. If scientists can pull this off, drop the cost of current SSD technology to 10 cents a gig! And, for the long-lived SSD storage, I'd be willing to shell out big bucks!
Don't forget to take into account the number of blocks which are in use. If you've got 50% disk use then expect the lifetime to be cut in half because the used blocks cannot be part of the remapping.
I've seen small devices burned out because 80% of the disk was the baseline before any user data got added.
No, he said reliability trumps speed.
You can't boot a PC off magtape.
Stupid fuckwit.
The review didn't mention the write factor in the calculations. Drives have a write factor which roughly relates the number of actual writes to user intended writes. This write factor has several variables (wear leveling, cell usage, garbage collection, TRIM, etc) that determine the ratio, but it's not uncommon for a drive to perform up to 5 or more physical flash memory writes for one user intended write. Assuming a 1:1 ratio of user intended writes to physical writes is an oversight that can greatly alter the results.
Having said that, it still takes a long time for most SSDs to start failing.
Even if it doesn't need to, it will.
And it is flakey still if you turn off swap, despite having more than enough memory for use.
OK, I don't really post all that much, but this post seems like it needs another reply. I have purchased SEVERAL SSD hard drives for the bunch of machines I have. The performance on them is awesome (which is why I still use them), but early on (and still a problem) I learned that their lifespan is crap. I haven't gotten more than 10 months out of any SSD, and I'm not defragging them or buying knock off brands that may or may not have fallen off the back of some production line. I have bought ones from Crucial, from WD, from IBM, and most recently (and the one that died last Tuesday) from Mushkin. It is to the point where I don't install anything except the OS on them, and still use a 7200RP platter drive and my Google Drive for all my data. That said...the performance alone is worth this annoyance, I figure it's not the end of the world to rebuild my pc once a year or so, and to do so with a freshly RMA'd hard drive. That said...I would ALWAYS suggest that people buy the "extended" warranties with these drives and keep important data elsewhere. The performance is great, but they don't last long at all.
There are plenty of enterprise SSD's that use SLC, both FusionIO and STEC offer SLC options and since STEC has been replaced by Samsung in many applications I assume they do as well. I know HP also offers them as an option for their Proliant servers.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
Dude, re-read my post. The laptop gets used almost daily for work in harsh environments. It doesn't get used for Facespace or other crap. What do you do, with a laptop, that a dual core 2.5GHz processor can't do? I'd like to have a newer faster machine. But, like I said in the beginning of this thread, I can't justify replacing a perfectly adequate laptop that's in mint condition.
Also, due to supporting lots of users and lots of machines, I have the opportunity to see the effects of different use cases on hard drives and keyboards etc. When I hear that you wear the letters off the keyboard every 12 months, I immediately think of my users. It seems that the PAs and transcriptionists that use hand lotion and antibacterials all the time wear out their keys in no time. But, the ones that don't have the creams and lotions on their desks have perfectly fine keyboards for a couple of years or more. Yet they're using the keyboards fairly equally.
So, before you go off like a condescending twat, re-read the post and try to apply some understanding before jumping to incorrect conclusions. kthnxbai
> you'd still find yourself waiting several months or even years for that SSD to start dying on you
How comforting!
Those who would give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety.
I have never had a laptop hard drive last more than two years, and only had one last more than eighteen months.
Then I would have to wonder what the heck you are doing to the hard drives. I'm not sure I've ever had one last less than that long in a laptop. I've had laptop hard drives last for 7 years and were still going strong when I stopped using the machine. In fact I usually have some other component die long before the hard drive does. I have several hard drives that work just fine from laptops with burned out system boards, defective keyboards, borked video and other problems.
Some people are quite hard on their equipment, perhaps you are one of these? I've often been astonished how carelessly some people treat their equipment and then expect it to work.
There are plenty of enterprise SSD's that use SLC, both FusionIO and STEC offer SLC options
Yeah but who is using them?
These arent used for massive server farms because regular drive failures are inevitable regardless of what you use. SLC flash mainly sees industrial and embedded use where small amounts of space actually gets used. If you have enormous amounts of storage then it would be very foolish to use expensive SLC's.
"His name was James Damore."
Apparently our definitions of plenty are different. FusionIO has ONE product w/ SLC. STEC has a few, but they are marked as industrial SSDs, just as I said in my original post.. and they are priced like industrial SSDs too.. about $1140 for 100gb. Industrial SSDs are typically $5-10 per GB... so that's right in line.
When you dont use a computer. That happens. And the fact that you are happy with a 2007 dell means you really dont use your computer.
Curious theory. The fact that I run a multi-million dollar company heavily using a half dozen computers between 6-9 years old must really mess with your world view. We run ERP , product test, shipping, time card management, several databases, some very large spreadsheets, CAD and quite a bit more but according to you we must not actually be using the computers for anything. Would a faster computer be nice? Sure but the marginal improvement would be well into diminishing returns.
I wear the letters off of a keyboard in 12 months.
So stop buying crappy keyboards. I have keyboards have have been used for over 20 years without a fleck of paint missing.
Some of us actually use their computers as tools to make money, others look at them as toys for fun.
Some of us actually try to get a decent ROI on our machines and realize that lots of actual work doesn't require the latest and greatest. I run a manufacturing company and if you don't think we don't use our computers I think you don't really understand what that means in the real world.
Slashdot comments are always about how SSDs are unreliable and fail constantly, but manufacturers can't seem to crank out SSD equipped devices fast enough. Macbook Airs and the entire Ultrabook category are based around SSD storage. These complaints about endurance never seem to line up with real world experiences. I've been through three SSDs in desktops (Vertex 1, Vertex 2 and Vertex 4 running on both Windows and Linux) along with an SSD equipped Macbook Air (from 2010) and I've yet to have a single issue. I've been trying to figure out what the disparity is between real empirical evidence and the slashdot crowd's assumption of performance, and the only thing I can think is maybe you're overestimating the write volume on normal desktop computers? Honestly I don't know. All I know is that the usage and sales don't correlate with this concern over failure rate or capacity Slashdot seems to have. Apparently performance trumps all.
Anyone using SSD in an EMC VNX or VMAX array is using SLC as they have yet to qualify any MLC drive to meet their 5 year guarantee. I know the SSD's in our new 3Par array are also SLC. I've used a mix of eMLC and SLC drives in our database servers, SLC for our OLTP ERP database and eMLC for our data warehouse BI database.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
Who knew?!
Those graphs are amazing.
of some sort of number manipuation that produces absolutely nothing.
I've been using an SSD since the start of Jan 2012 to the present as a the sole drive for a gaming system: http://www.newegg.com/Product/Product.aspx?Item=N82E16820171567
It's still running strong and the load times are noticeably faster in all games over my previous 10k Raptor. Other than being a bit small, it serves my needs perfectly.
Grain of salt, YMMV, etc.
You just don't write that much data on a desktop. Yes, when you do a reinstall you write a lot but it really slows down after that. You can measure it and you find that really it is a somewhat rare day that you write a gig to your disk much less more.
Also all drives are over provisioned, there is space you don't see that they can use to swap in and out for wear leveling. This happens behind the scenes, beyond your control.
So the drive really will last quite a long time. If your use is desktop use, don't worry about it, buy a drive and enjoy it. Only for write intensive use do you need to do any calculations on it. If you want it as a backend for a database server, or you are using it to capture uncompressed video then yes, throw some math at it before you buy. However for a desktop? No, it won't be a problem.
We've already seen people with less than 2ys (CITATION NEEDED? IT'S CALLED GOOGLE) life on their new SSDs and as another poster pointed out the write cycles are SIGNIFICANTLY less than the ridiculous number the article said.
Something tells me SSD manufacturers are *desperate* to maintain the illusion that their products are worth anything and are paying "reviewers" to come up with as much BS as humanly possible to assure people that these still-overpriced pieces of garbage are worth buying.
So far I see a lot of complaints from people who don't appear to even know how to run SMART tools to get write cycle and wear statistics from their SSDs... you know, so real actual numbers can be posted.
So far none of my SSDs have failed, and I have almost 20 installed in various places. The one with the most wear is one of the first SSDs I purchased, an Intel 40G device:
da0: Fixed Direct Access SCSI-4 device
da0: Serial Number CVGB951600AC040GGN
da0: supports TRIM
Power on hours - 19127
Power cycle count - 48
Unsafe shutdown count - 32
Host writes x 32MiB - 375697
Workld media wear - 5120
Available reserved - 99/99/10
Media wearout - 91%
Basically 12TB worth of writes on this 40G drive over the last 2.18 years. No failures. Media wearout indicator 99 -> 91. Estimated durability based on the wear indicator is around 132TB. Roughly comes to ~3300 cycles/cell. This vintage of SSD uses MLC flash whos cells are roughly spec'd at ~10000 cycles.
While firmware issues are well documented for various SSD vendors over the last few years, and cell erase cycle life has gone down as the chips have gotten more dense, I would still expect the vast majority of failures to be due to wear-out.
Lots of things can cause premature wear-out but probably the most common would be using the SSD for something really stupid, like to host a database doing a lot of random writes or with a high frequency of fsync()s, using the SSD for swap on a system which is paging heavily 24x7, using the SSD for WWW log files on a busy web server, formatting an unaligned filesystem on the SSD or a filesystem which uses too-small a block size, and any number of other things.
Venerable but still mostly correct:
http://leaf.dragonflybsd.org/cgi/web-man?command=swapcache
The only adjustment I would make is that as the Intel 40G continues running, the wear I'm getting on it is pointing closer to ~130TB of durability and not 400TB (400TB is the theoretical max at 10,000 cycles/cell). Still reasonable. Generally speaking, that's the older 34nm technology. The newer 24nm technology will get fewer cycles but devices tend to have more storage so, as I say in the manual, you could expect similar total wear out of a newer 120GB 310 series SSD whos flash cells have 1/3 the cycle life.
-Matt
Seriously, if you are worried, get an SSD that monitors itself. Samsung and Intel are good choices. They monitor how much actual writing has been done and give you a life estimate and so on. You will discover that no, you really don't do as much as you think most likely.
Also, Windows knows if you have an SSD in a slot and knows how to deal with it.
Does that also apply to SD and micro-SD cards? Nowadays these Raspberry Pi and comparable devices use micro-SD cards to run the operating system. I have the impression that typical flash cards and USB sticks nowadays use 4 MB erase blocks and the wear leveling on these is probably not very smart, so just a /var/log/syslog on a 4 GB card that gets a line every minute will wear itself out in about 2 years.
Actually I have had a couple of sd cards fail on me (one Nokia 2 GB dead on arrival (2008), later on an 8 GB and 2 GB card on other phones in the last two years within a two years after purchase).
On a related note: I wished that manufacturers of those thumb drives and sd cards specified not only sequential read/write throughput but also write throughput for random 4 kB blocks. With many drives, throughput will drop to 20 kB/s. (Source: http://forum.micromart.co.uk/Topic413730.aspx )
Avantslash: low-bandwidth mobile slashdot.
I did a LOT of work with RamDrive software decades ago that did very well... & here's some "ideas" you can use &/or apply to YOUR idea (good one by the by), albeit to a Linux machine (vs. Windows, which is my preference/weapon-of-choice) - principles are the same though with these excellent tools (ramdisks/ramdrives):
I do the list below, here on my home system, & PARTIALLY @ least, just to avoid JUST WHAT YOU SPEAK OF (wear & tear on HDD's specifically, as well as LESSENING THEIR WORKLOAD).
However, there's another 'benefit'!
IF/WHEN you remove these tasks/items working on your main drive, usually a harddisk drive (slowest part of computers typically)?
THUS - You let it essentially also WORK FASTER fetching programs & data also by lessening the slowest thing having to do the work!
---
A.) Pagefile.sys (this you MAY want to "steer clear of" with software based ramdisks UNLESS you have 'tons of ram', up to you!) - remember: I do this on a solid-state unit (more below on that) nowadays though...
B.) OS & Application level logging (EventLogs + App Logging)
C.) ALL WebBrowser caches, histories, sessions & browsers too
D.) Print Spooling
E.) %Temp% ops (OS & user level temp ops)F.) %Tmp% ops (OS & user level temp ops)
G.) %Comspec% (command interpreter location)
* & more...
---
Nowadays?
I use a "True SSD" based on DDR-2 RAM for the above though (in the 4gb Gigabyte IRAM)
HOWEVER - You can't TOUCH speed of system memory though, not with SSD's, & that's where RamDrive utilization, if you have enough RAM that is, ROCKS!
* Some "Food 4 Thought" for you there above...
I have been doing work for DECADES with ramdisks/ramdrives, they're useful & excellent IF/WHEN applied correctly!
(Even to the point of writing up my own based on the MS DDK + a front-end adjustment system for it in GUI that was simple to use -> http://www.google.com/search?hl=en&output=search&sclient=psy-ab&q=%22APK+Ramdisk%22&btnG=Submit&gbv=1&sei=pTIkUafQM-qx0AGz_4HIDQ ).
APK
P.S.=> That last link above led to this (one of my 'finest moments' personally, in computing):
Windows NT Magazine (now Windows IT Pro) April 1997 "BACK OFFICE PERFORMANCE" issue, page 61
(&, for work done for EEC Systems/SuperSpeed.com on PAID CONTRACT (writing portions of their SuperCache program increasing its performance by up to 40% via my work) albeit, for their SuperDisk & HOW TO APPLY IT, took them to a finalist position @ MS Tech Ed, two years in a row 2000-2002, in its HARDEST CATEGORY: SQLServer Performance Enhancement).
... apk
http://slashdot.org/comments.pl?sid=3475241&cid=42951835
* :)
(Only thing that's "held me back" from using these FLASH based SSD's is wear longevity... I opted for another solution, noted below, until they are PROVEN in this area, & better so!)
Doing what I listed there for the parent poster's ideas I replied to (decent ones, 'great minds think alike' & all that, albeit many years after I did, lol) has another "ancillary benefit" besides faster seek/access performance & such"
It lessens the workload on the SLOWEST part of typical computers: Hard Disk Drives, along with increasing their longevity BY LESSENING THEIR WORKLOAD!
Which, of course, also "speeds them up" by doing so in lightening their workloads, & allows FASTER program + data loads, bonus, as well as increasing their life.
APK
P.S.=> There's some "ideas" for you that I used to apply to software-based ramdrives, & LATER did very well on (which others are NOW only "stumbling into" for performance purposes in industry etc. really the past few years now).
However - NOW, instead, I use a "True SSD" as I call it, based on DDR-2 RAM instead in the Gigabyte IRAM for those listed items in the link above!
(Yes, not as fast as system ram, but faster than mechanical HDD's are in access/seek by FAR, but the bus used isn't as fast as system RAM is either, trade-off)
The ideas/techniques listed in the link above, however, DO still apply with ramdrive software - 1st's "iffy" if you don't have the RAM for it though!
(Ramdrive Softwares are nice, in that they use system RAM, nearly "as fast as it gets" (vs. cache ram types) & no "choking" by bus speeds like I get with the SSD I use (not really an SSD in 'modern terms' but close enough & I *think* you get my point/'catch my drift'))...
... apkcid=42951835
Windows NT Magazine (now Windows IT Pro) April 1997 "BACK OFFICE PERFORMANCE" issue, page 61 - to an EXCELLENT review & far more noted below as well!
(For work done for EEC Systems/SuperSpeed.com on PAID CONTRACT (writing portions of their SuperCache program increasing its performance by up to 40% via my work) albeit, for their SuperDisk & HOW TO APPLY IT, took them to a finalist position @ MS Tech Ed, two years in a row 2000-2002, in its HARDEST CATEGORY: SQLServer Performance Enhancement).
Ramdisks/Ramdrives are also useful for "scratch/temp" space work as well... especially with database engines!
---
By using Ramdisk/RamDrive software!
(way, Way, WAY before it was 'mainstream' to design DB engines with their OWN dedicated device space in memory (essentially a ramdisk))
It is also 'funny' that usage of SSD's, which ARE THE SAME PRINCIPLE as ramdrive software in essence, are "taking the planet by storm" in industrial environs ONLY THE PAST FEW YEARS NOW (want citations? Ask) FOR BETTER PERFORMANCE TOO, eh?
APK
P.S.=> Was doing it with DBase III stuff YEARS BEFORE THAT TOO, & it just works using ramdrives since the seek/access ALONE is incredibly faster, & hdd's are orders of magnitude slower on writes...
... apk
Caches, "flush" out - Especially if "forced" by memory starvation &/or paging!
In fact? They're the FIRST thing that "takes a beating" since they are designed to be "dynamically" changed, on-the-fly & depending on the algorithm &/or design used (FIFO, LIFO type queing, aging engine, + set associative design type), it can be WORSE in some cases, because of the above.
(Ramdisks when done via software into fast system RAM, by way of comparison - DON'T... Since they're 'static' in nature via device drivers in Windows, which makes them valuable in the capacities I noted here -> http://slashdot.org/comments.pl?sid=3475241&cid=42951835 AND, which "overcome your objection"...)
APK
P.S.=> Point on your part, good one, but that's my counter... & IF/WHEN you use Ramdisks in the capacities I noted in my replies here!
(As well as the parent posters' ideas, decent ones)
They work...
In fact, don't KNOW if you "caught this" or not, but, I did well in it professionally to GOOD notoriety & review in my day, "back in the day" 1996-2002 with them, & it changed the design of db engines in fact - why do you *think* they use a dedicated 'device' in memory, as in SQLServer?
NON-FLUSHABLE like diskcaches!
(See the link above on that note, near its termination)
Simply because of the nature of diskcache design + purpose, & using ramdrive software, judiciously, overcomes it (or static devices in memory like DB engines use)...
After all: "Proofs in the pudding" (results I got noted in that link & good review in a VERY highly esteemed publication as well as the same ilk in tech trade shows)...
... apk
I have used a lot USB flash sticks for operating systems, and they wear out fairly fast. A couple of weeks is typical.
I am currently using SanDisk short sticks, and they have lasted the longest so far.
It may be too late for this post, but Allyn over at pcper.com posted up some analysis of this article and that it leaves out important data:
Max data write speed did not take into account 8/10 encoding, meaning 6Gb/sec = 600MB/sec, not 750MB/sec.
The flash *page* size (8KB) and block sizes (2MB) chosen more closely resemble that of MLC parts (not SLC – see below for why this is important).
The paper makes no reference to Write Amplification.
"Write Amplification would be a factor of 500, meaning the flash memory is cycled at 500x the rate calculated in the paper." Gulp.
http://www.pcper.com/reviews/Editorial/Taking-Accurate-Look-SSD-Write-Endurance
I note "in memory devices" in them, ala SQLServer -> http://slashdot.org/comments.pl?sid=3475241&cid=42952517 (see near its termination).
* :)
(Been doing MIS/IS/IT & DB Engines for with many wares for it (ala Oracle, MS SQLServer, DB/2 & even other smaller ones professionally since early 1995)).
APK
P.S.=> Where'd you think the idea came from? See my link again... apk
Try it yourself... you'll STILL see paging activity (albeit from executables).
* :)
I know this since I've had to explain it to others online before who couldn't understand WHY even though they eliminated paging completely (which doesn't in Windows, it will try to FORCE a minimum 16mb sized on on main OS bearing disk OR temp one, no getting around it either).
However - Executables "page back to themselves" on disk (fact, look it up).
APK
P.S.=> Sometimes, it's by design & in the app itself! I do it to conserve RAM not 'painting controls' until say, a tab is VISIBLE In a multi-tab program for instance & tabbed apps are the best way to see it in fact, try it... &, others times it's by design in the OS memmgt subsystems (in kernelmode, they are, after all, Virtual Memory mgt. systems, & it's ALL "Virtual Memory" to modern OS)...
Again, DO try it yourself (that is what explains that paging activity in fact)... apk
his data and math is quite wrong
Purely relative term (I mean like the max modern systems will hold today, not sure what largest RAM sticks are nowadays or max amount of slots in a mobo nowadays is (server boards especially probably have more) in 64-bit OS, but I know they don't TOUCH what is possible in 64-bit address range capable OS yet)?
It *could* be used to avoid diskbound paging latencies (especially IF you aren't even BEGINNING to 'scratch' what you have available, that is, & have a large excess).
* Think about it - "Food 4 Thought"... & can ANYONE tell me what the most possible slots on mobos are, & what largest RAM stick sizes are nowadays (I haven't bought a new mobo since 2009 & things change)... thanks for the answer, it may give us some "hard numbers" perspective here too on that account.
APK
P.S.=> Yes, you can "avoid" that on your main OS &/or Programs bearing disk (in MS stuff, say C: drive, or whatever device you mount in *NIX's) by moving the paging files to another drive... but, you STILL would have the diskbound latencies I noted on HDD's - what I said above MIGHT avoid all that, entirely!
... apk
http://www.anandtech.com/show/6459/samsung-ssd-840-testing-the-endurance-of-tlc-nand
Go to Heaven for the climate, Hell for the company -- Mark Twain
Hairy Feet,
I like what you said in this thread. It's helpful.
I have talked with two Intel employees who said they work in two different groups at Intel concerned with how processors interact with storage. They said Intel's SSD caching risks data integrity, and it is not possible to RAID Mirror Intel's SSD caching using Intel's Ivy Bridge chipset.
Also, quoting from the Intel Rapid Storage Technology RAID driver GUI: "The Windows write-cache buffer flushing policy can be enabled for all RAID array drives to ensure data integrity or disabled to improve data performance. Click the Help icon for more information on setting the wnte-cache buffer flushing policy based on your needs."
Based on talking with Intel employees, I have developed an opinion that SSDs and SSD interaction with processors are still in development stages. There are, it is apparent to me, many poorly managed groups at Intel. Only the CPU design group has been consistently successful. It's only my guess, but I'm guessing that former Intel CEO Paul Otellini was fired by Intel's board of directors for an especially severe issue of bad management.
I should have said that in my opinion, "Only the CPU and chipset design groups have been consistently successful." Also, that is only an outsider's opinion. There may be well-managed groups inside Intel that are unknown to me.
Nope. I decided that I don't need the technology some years ago, and have seen nothing to cause me to re-think that position. I don't need "super-fast boot times" because I re-boot every few weeks. The amount of data that I keep around and want to access is high enough that SSDs aren't in the feasible price range, and the main constraint on me finding stuff is thinking "where would I have put that?" Which is much faster than brute-force searching.
Birds are not dinosaur descendants;birds are dinosaurs, for all useful meanings of "birds", "are" and "dinosaurs"
For YEARS now (first with this unit) -> A Gigabyte IRAM 4gb unit!
It's EXACTLY where I place my pagefile.sys (in Windows), & I noted it here (also noting that it's "iffy" do with ramdrives in the link below, UNLESS you have a "ton" of RAM & especially RAM that does unused).
* See here -> http://slashdot.org/comments.pl?sid=3475241&cid=42951835
That's ALL of what I do on a "True SSD" as I call it (well, almost, missed 1 part noted below...).
Thus "mirroring your idea" (my idea too, lol, from a LONG time ago when I used to do it 1st on ramdisks in software, & then later on another "True SSD" from 2000 onwards called a CENATEK "rocketdrive" but it was based on slower PC-133 SDRAM & used a slower bus (PCI 2.2.)).
The Gigabyte IRAM's based on DDR-2 RAM, & also a PCI Express buslane (faster all the way around) BUT, is limited by emulating a SATA disk though (that's where a ramdisk in software 'rocks it', far, Far, FAR faster in the respect - throughput!)).
I omitted this in my list there in the link above:
I also place my custom hosts file onto it, via redirecting WHERE it's referenced by the OS, here in the registry:
---
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters
And the "DataBasePath" parameter there...
---
Which also acts more-or-less, like a *NIX shadow password system also!
(That's good, vs. any malware that *might* attempt to 'mess with it since the original residing in %WinDir%\system32\drivers\etc is pretty much only a 'decoy' @ that point, lol!)
However, modern Windows uses UAC to protect it, & I also apply read-only rights to it to supplement that, & my hosts file import/deduplicate/favorites hardcoder mgt. system I wrote -> http://www.start64.com/index.php?option=com_content&id=5851:apk-hosts-file-engine-64bit-version&Itemid=74 does the rest!
Supplementing UAC, by doing that read-only write protection attribute applied every 1/2 second & NOTHING will 'blow past that' (it's essentially locked that way vs. malicious interlopers!)
Anyhow/anyways: I place mine & all else on that list in the 1st link above onto that "True SSD" as I call it!
Just for faster loading since the seek/access is in the ns range, rather than HardDisk ms ranges!
(That's many orders of magnitude faster, for loading faster into RAM + I let the local kernelmode diskcaching subsystem cache it too, rather than the faulty-with-larger hosts files local DNS clientside cache service in Windows (known issue in it for ages, & MS doesn't fix it - so I said "hell with it" & opted to do it THAT way + I constantly am online, & that KEEPS it there, so the cache doesn't flush it out, by being online nigh constantly)).
APK
P.S.=> And, "There Ya Go" (& 'great minds think alike') - Oh, & I "did some checking" just for my OWN reference, & it appears that 8gb ramsticks are the max size now, & considering you can put usually up to 16gb into current std. mobos, & up to 32gb into server boards? The ramdrive pagefile.sys (or *NIX file analog) IS a possible, IF you don't 'suck that up' for other things, keeping in mind using it JUDICIOUSLY for things you don't WANT flushed by say, a cache (they are volatile's why)...
... apkid=5851:apk-hosts-file-engine-64bit-version