Main Area and Open Discussion > Living Room
A three drive system - the sweet spot
40hz:
If you're not rebooting, or are opening and closing apps constantly, I'm not sure how big a speed advantage an SSD would give you in actual use.
I'd definitely think about upping RAM (to between 8-16 Gb) before I sprung for an SSD. And if it were a desktop PC - and I had money left over after adding more RAM - I'd then spring for a faster video card.
I'm not trying to dis SSD drives. They're certainly a nice bit of kit. But I personally feel the benefits they bring to the mix are somewhat overblown. But that's probably more me and what I use a PC for. YMMV.
Jibz:
^^ Amen. I've heard it since SSD's came out that the swapfile (pagefile on Windows) should go on a fast but non-SSD Disk. Hadn't thought of the temp and log files, good catch.
-Edvard (March 22, 2014, 07:13 PM)
--- End quote ---
I think for most recent SSD drives, the controller is likely to die years before the read/write tear of the temp folders is going to make a dent. I can't find anything backing this up though, most tutorials seem to reiterate the wisdom of five years ago.
Regarding the pagefile, here is a Microsoft Q&A from 2010 stating some usage data for the pagefile (near the bottom) and recommending keeping it on the SSD.
40hz:
I think for most recent SSD drives, the controller is likely to die years before the read/write tear of the temp folders is going to make a dent. I can't find anything backing this up though, most tutorials seem to reiterate the wisdom of five years ago.
-Jibz (March 23, 2014, 01:49 AM)
--- End quote ---
I'm looking at this more from a server perspective (since that's where my experience chiefly lies). But there's enough in common between PCs and servers that I think what applies to one pretty much applies to the other as far as hardware goes. Two articles worth looking at are here and here.
The first (from March 2014) discusses "SSD myths and legends."
SSD endurance - should you worry? - and why?
Flash wear out still presents a challenge to designers of high IOPS flash SSDs as the intrinsic effects at the cell level get worse with each new chip generation.
That's in contrast to RAM SSDs - where as long as enterprise users remember to replace their batteries periodically - the memory life is more dependent on elapsed time (classic bathtub reliability curve) and heat stresses rather than directly related to the number of R/W cycles.
Higher SSD capacity, and faster speeds come from progressively smaller cell geometries - which we used to call shrinks. In flash memory small size means less trapped charge holding the stored data values and greater sensitivity to charge leakage, charge dumping and disturbance effects from the normal processes which happen around the cell vicinity during R/W, powering up, powering down etc.
If you're a consumer you don't have to worry about the internals of endurance management - because most new SSDs are good enough (if they're used in the right applications environment).
Exceptions still do occur, however for users in the enterprise SSD market - where I still hear stories of users thinking it's perfectly normal and economic to replace burned out Intel SSDs every 6 to 12 months - instead of buying more reliable (but more expensive) SSDs - from companies like STEC.
But if you're a systems designer it's useful to know that the longevity difference between "good enough" and the best endurance architecture schemes can still be 2x, 3x or 100x - even when using the same memory.
In 2011 - new evidence started coming in from longtitudinal flash SSD research done by STEC that old, heavily written MLC cells - managed by traditional endurance schemes - tend to get slower as they get older - due to higher retry rates on reads - even though the blocks are still reported by SMART logs as "good" - and the writes do eventually succeed on retry.
In the same year - a paper by InnoDisk confirmed that whereas SLC and MLC memories have often had endurance populations within each chip which were mostly much better than guaranteed (something which SSD makers had been telling me since 2004) - the headroom / margin of goodness - in newer types of MLC is lower than in the previous MLC generations. That's why controllers which used to work well with vintage MLC need something much stronger than a tweak to deliver well behaved SSDs when co-starring with the new brat generation of naughty flash.
--- End quote ---
The second (February 2012) is from AnandTech :-* and goes into the issue with their usual mind-numbing level of attention to detail.
One very interesting recommendation:
We also showed a clear relationship between performance and drive capacity/spare area. Sizing your drive appropriately for your workload is extremely important for both client and enterprise SSD deployments. On the client side we've typically advocated keeping around 20% of your drive free at all times, but for enterprise workloads with high writes you should shoot for a larger amount. How much spare area obviously depends on your workload but if you do a lot of writing, definitely don't skimp on capacity.
--- End quote ---
Some other good stuff in the article. It's confined to one brand of SSD, but since the technology is similar to what’s in other brands I think most of it should still be valid - bearing in mind this article is now 2 years old.
Dunno...I'm still a tiny bit leery of using SSDs for anything really valuable. :tellme:
Stoic Joker:
The first hard drive (C) on the computer should be an SSD. These are super fast, and affordable when the sizes are small (250 gb or so). This will be your Operating System drive and where (most of) your program files get installed. My philosophy is that this drive is too small to hold everything, and too unreliable to hold your documents.
-mouser (March 22, 2014, 02:57 PM)
--- End quote ---
If you're running a server, make sure your temp and logfile directories are all residing on another standard drive too. I'd suspect all that constant reading and writing is probably not too healthy for an SSD. And servers generate a lot of logging and scratchpad activity.
Just my :two: :)
-40hz (March 22, 2014, 03:51 PM)
--- End quote ---
Okay, first off I agree with you. I'm not a huge fan of SSD either. But... If the Temp file is on a more reliable - longevity wise - "Standard" (e.g. slower) drive, then it stands to reason that any process that is dependent on doing its workload in/out of the temp folder would then be restricted to/by the performance of the lower speed (presumably) mechanical drive. So wouldn't that negate the purpose of using a SSD? ...Or am I missing something?
I'm thinking that with the huge amounts of memory in machines these days are making the PageFile an almost moot point, so anything active in memory will most likely stay there. Then why not push the high traffic and ephemeral work areas off onto the higher speed (and arguably grenade prone) disk to keep the overall disk failure data loss exposure down? Sure you might - damn the luck on timing - lose the latest changes on the current project...but you're not going to lose all the projects in the folder next to it.
Lightning fast boot times might - well yeah okay they are - be important for laptops and tablets. But for a desktop that has a much longer typical running cycle the extra 30 seconds is really that big a deal. The same thing could also be applied to application load times, laptop/tablet...gotts to be zippy ... Desktop...not so much.
mouser:
Lightning fast boot times might - well yeah okay they are - be important for laptops and tablets. But for a desktop that has a much longer typical running cycle the extra 30 seconds is really that big a deal. The same thing could also be applied to application load times, laptop/tablet...gotts to be zippy ... Desktop...not so much.
--- End quote ---
I can't really disagree with the logic of this.. In fact we should say that even for laptops, most people, most of the time, will be waking from sleep, which is extremely fast on Windows these days, and involves little drive activity.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version