Advantages of a bigger SSD

[pcslookout]

Right now I have a Crucial 120 GB SSD but may want to upgrade to the 256GB version. Is it worth it ?

I will still keep the original one. Not sure for what though. Is it ok to put VMs and games on a SSD ?

 

[bradley]

More channels = more speed. The Marvell 88SS9174 especially benefits from the additional channels. You didn't state which drive you own. Also having one 120GB vs. 2 x 120GB frees an extra SATA slot and maintains TRIM, if you decide to RAID.

I would sell the extra drive to fund your purchase, or you could use it as a data drive or an RST cache (in Intel Z68 mobos) for your HDD. Make sure to check Slickdeals.net, as there have been lots of deals on the Crucial M4 (and lots others) recently.

 

[kbp]

Personally I would just buy another one and RAID-0 them. This gives you 240 to work with and is probably the cheapest way to go. AND, you get the performance benefits to.

 

[bryanW1995]

Raid 0 on 120 gb ssd's isn't much faster than that same drive in a 240gb configuration though, right?

 

[TakeNoPrisoners]

Raid 0 on 120 gb ssd's isn't much faster than that same drive in a 240gb configuration though, right?

Wrong, a 240GB SSD will be slightly faster then a single 120GB SSD. But two 120GB SSDs in RAID 0 will be nearly double the speed of a single 240GB SSD.

With SATA 3 you start approaching 1GB/s on RAID 0.

 

[Anteaus]

Too bad those are just read speeds. You get to a point where the the law of diminishing returns comes into play. If it takes you 3 seconds to load a program with the single, but can load in 1.5 seconds with the double, is it worth the additional complexity of using raid? Other than getting fantastic benchmark scores and bragging about them of course.

 

[taltamir]

Wrong, a 240GB SSD will be slightly faster then a single 120GB SSD. But two 120GB SSDs in RAID 0 will be nearly double the speed of a single 240GB SSD.

With SATA 3 you start approaching 1GB/s on RAID 0.

Except, lack of TRIM will seriously hurt your performance and potentially lifespan of drives.

Also sequential reads are fine and dandy but random reads/writes are also important and those are not limited by SATA controller.

 

[kbp]

Except, lack of TRIM will seriously hurt your performance and potentially lifespan of drives.

Also sequential reads are fine and dandy but random reads/writes are also important and those are not limited by SATA controller.

Trim is right around the corner. Intel has announced TRIM will be supported with the full 11.5 version. Personally, I still would over-provision my SSD's even with TRIM. GC is a much better way of cleaning NAND.

 

[greenhawk]

Trim is right around the corner. Intel has announced TRIM will be supported with the full 11.5 version

only with a intel chipset, but then, Intel have been saying "right around the corner" for so long now, I'll believe it when it arrives.

 

[taltamir]

Trim is right around the corner. Intel has announced TRIM will be supported with the full 11.5 version. Personally, I still would over-provision my SSD's even with TRIM. GC is a much better way of cleaning NAND.

1. Over provisioning is always good for you, TRIM or GC.
2. 11.5 version is not out yet. When it is available however then it would be awesome since you would not have to choose between TRIM and RAID0.
3. GC is NOT better than TRIM, to even suggest so shows horrible ignorance of what they do.

TRIM notifies the controller about file deletion immediately so it knows that the space they used to occupy is no longer used.
GC is an algorithm wherein the drive controller uses idle cycles to read the content of the drive, locate deleted files (marked only in the FS; works only with compabile FS, typically NTFS and FAT) and then marks those files as having been deleted as it finds them.

If you have a drive that is 100GB with 20GB overprovisioned and 80GB available to user. And of that 80GB, you use 30GB and 50GB is free space. You the uninstall a 10GB video game leaving you with 20GB used and 60GB free.

With TRIM the drive immediately gets that info and is counted as having 20GB of used space and 80GB of free NAND (free space + over provisioning).

With GC you are counted as having 30GB used and 70GB free. You will slowly recover those 10GB over the next few hours. however in the meantime additional writes may accumulate there.

With neither GC nor TRIM you are going to, once having written 80GB since your last secure erase, be at a "used state" where the drive controller considers you to have 80GB used (used space + free space) and 20GB free (over provisioning only)

only with a intel chipset, but then, Intel have been saying "right around the corner" for so long now, I'll believe it when it arrives.

And that is another issue, yes.

 

[bryanW1995]

1. Over provisioning is always good for you, TRIM or GC.
2. 11.5 version is not out yet. When it is available however then it would be awesome since you would not have to choose between TRIM and RAID0.
3. GC is NOT better than TRIM, to even suggest so shows horrible ignorance of what they do.

TRIM notifies the controller about file deletion immediately so it knows that the space they used to occupy is no longer used.
GC is an algorithm wherein the drive controller uses idle cycles to read the content of the drive, locate deleted files (marked only in the FS; works only with compabile FS, typically NTFS and FAT) and then marks those files as having been deleted as it finds them.

If you have a drive that is 100GB with 20GB overprovisioned and 80GB available to user. And of that 80GB, you use 30GB and 50GB is free space. You the uninstall a 10GB video game leaving you with 20GB used and 60GB free.

With TRIM the drive immediately gets that info and is counted as having 20GB of used space and 80GB of free NAND (free space + over provisioning).

With GC you are counted as having 30GB used and 70GB free. You will slowly recover those 10GB over the next few hours. however in the meantime additional writes may accumulate there.

With neither GC nor TRIM you are going to, once having written 80GB since your last secure erase, be at a "used state" where the drive controller considers you to have 80GB used (used space + free space) and 20GB free (over provisioning only)



And that is another issue, yes.

That looks like a very good description of TRIM vs GC. Why, then, was the x25m g1 so good even after it was "full"? Did they have some sort of old-timey GC on them, tons of overprovisioning, etc etc?

 

[philipma1957]

That looks like a very good description of TRIM vs GC. Why, then, was the x25m g1 so good even after it was "full"? Did they have some sort of old-timey GC on them, tons of overprovisioning, etc etc?

tons of over provisioning. an intel 80gb had lots more space for garbage.


As for ssds to like 240gb and 256gb are best. Also intels new 180gb is a nice ssd (a bit pricey)

http://www.newegg.com/Product/Produc...uxe%20240%20gb


this drive is effing amazing sells out as soon as it comes in. Read my thread on it's use in macminis and in

seagate t-bolt adapters.


http://forums.macrumors.com/showthread.php?t=1317577


I have two of them. really nice ssd. the thread above is on mac rumors the thread talks about a lot of ssds tested by me and others for use in the seagate t-bolt adapter.

so far the mushkin 240gb is best. the talk on the mushkin 240gb starts on the 6th page of the thread.

 

[wpcoe]

@taltamir: Thanks for that explanation of TRIM vs GC. :thumbsup:

 

[F1shF4t]

tons of over provisioning. an intel 80gb had lots more space for garbage.

Actually no, the x25-m G1 had 80GiB of NAND with 74.5 or so available to the user. The G2 was exactly the same but supported trim.

Trim will reduce your write amplification and depending on the controller will keep the drive performing faster.

Garbage collection has no knowledge of the file system either, when the OS writes new data into LBAs that the controller previously had allocated, the old pages in NAND associated with these LBAs will be marked as invalid. The SSD controller will then read and re-write valid data so that it can erase the blocks with the invalid pages. (data is written in pages but can only be errased in blocks) Trim makes this process more efficient as you would know which data is invalid straight away instead of waiting when its overwritten.

 

[philipma1957]

Actually no, the x25-m G1 had 80GiB of NAND with 74.5 or so available to the user. The G2 was exactly the same but supported trim.

Trim will reduce your write amplification and depending on the controller will keep the drive performing faster.

Garbage collection has no knowledge of the file system either, when the OS writes new data into LBAs that the controller previously had allocated, the old pages in NAND associated with these LBAs will be marked as invalid. The SSD controller will then read and re-write valid data so that it can erase the blocks with the invalid pages. (data is written in pages but can only be errased in blocks)

Thanks for info I guess I had the wrong Idea/memory about what I had read in a review years ago on that drive.

I had thought it had much more then 80gb and used it as hidden GC. The review would be more then 2 years old. Maybe someone has a link and my memory is not that faulty.

 

[bryanW1995]

Ok, so no obscene about of over-provisioning. I wonder if maybe they did run some rudimentary form of GC on them. I don't remember Anand talking about the reasons for continued excellent perfromance even after they filled up, though intel probably didn't tell him at the time. Regardless, it's moot now since all good ssd's these days have GC + TRIM, anyway.

 

[bryanW1995]

Thanks for info I guess I had the wrong Idea/memory about what I had read in a review years ago on that drive.

I had thought it had much more then 80gb and used it as hidden GC. The review would be more then 2 years old. Maybe someone has a link and my memory is not that faulty.

You're thinking about the x25e, those guys were overprovisioned by what at the time seemed like a very large amount (96gb of nand on the 80gb ssd iirc).

The link is in the ssd's/storage section of the main page on Anandtech. You need to go back 7-8 pages to find it.

 

[moriz]

RAID0 only improves on sequential performance, but does nothing for 4K random transfers, which is what's giving SSDs their superior responsiveness. as such, RAID0 on two SSDs won't actually result in any perceivable performance gain, except when transferring large files. however, the media it is transferring to/from has to be able to hit the same speed. two modern SSDs in RAID0 can hit around 1GB/s, and as far as i know, there aren't anything nearly as fast in storage devices, except another RAID0 SSD array.

basically, do RAID0 if you want to make two smaller SSDs appear as one bigger drive, but never do it because you except a performance boost, because you likely aren't going to get one.

as for the loss of TRIM and drive longevity, i've noticed no performance loss nor significantly faster wear when i ran an intel 320 120GB RAID0 array for seven months. both drives still report 100% on its wear meter by the end of it, and there was never any speed degradation.

 

[taltamir]

Why, then, was the x25m g1 so good even after it was "full"? Did they have some sort of old-timey GC on them, tons of overprovisioning, etc etc?

The g1 was so good because it had 10 channels while competing controllers had 4 at most.
10 channels means it can concurrently write to 10 separate NAND die in parallel, it is in fact superior to RAID0 of 10 drives.
It complemented it with a well designed controller that did a lot of other things right.

I don't quite remember if it had GC or not, IIRC it did not since the problem of "used state" was not well known then.

Garbage collection has no knowledge of the file system either, when the OS writes new data into LBAs that the controller previously had allocated, the old pages in NAND associated with these LBAs will be marked as invalid. The SSD controller will then read and re-write valid data so that it can erase the blocks with the invalid pages. (data is written in pages but can only be errased in blocks) Trim makes this process more efficient as you would know which data is invalid straight away instead of waiting when its overwritten.

You are wrong.

What you describe is not garbage collection but worst case scenario "used state" SSD with neither GC nor TRIM.
Where LBAs are only marked as being clear when they are written into.

A 10 second search for "garbage collection anandtech" found the following
http://www.anandtech.com/show/3997/ocz-revodrive-x2-review/4

The principle behind idle garbage collection is simple. When the SSD controller detects a period of no activity, it can query the file system for available addresses, and then internally mark those addresses for cleaning.

As you can see, it has to query the file system. This means it needs to recognize the file-system being used.

Here is info on block recycling engine and how it does what you described
http://www.anandtech.com/show/4159/ocz-vertex-3-pro-preview-the-first-sf2500-ssd/6

 

[pitz]

If you need the extra space, fine, go buy a bigger SSD. But if you don't, then you're just wasting money unless you're upgrading to get a better performing drive overall (since newer drives tend to be faster than old ones).

I've yet to hear of anyone, unless they've specifically set out to deplete the write cycle capacity of a SSD, actually managing to do so. Other sorts of electrical failure, power surges, or simply relegating the drive to a HTPC or other sort of device, is a far more likely scenario.

IMHO, SSD makers are setting themselves up for a massive glut. The first batches of laptops with SSDs are now going into obsolescene, and the used SSDs will be likely turning up in the resale channels in droves.

 

[taltamir]

I've yet to hear of anyone, unless they've specifically set out to deplete the write cycle capacity of a SSD, actually managing to do so.

I have, here in the forum.
IIRC I calculated the person in question was getting massive write amplification of over 100x (theoretical max is 128x) and theorized it was due to him not having TRIM.

I wanted to prove it by having him run some tests but he disappeared on us.

On the other hand, I have been using TRIM since day 1. Check out my write amplification and drive health last time I calculated in my signature.

IMHO, SSD makers are setting themselves up for a massive glut. The first batches of laptops with SSDs are now going into obsolescene, and the used SSDs will be likely turning up in the resale channels in droves.

While this might happen, and will cause a temporary downturn in sale, new drives are significantly faster then older drives.
Yes the difference is not as big.

Going from a HDD to a GOOD SSD can give you 100x the random read/write at same to 4x sequential speeds.
Random access is not necessarily more important, heck its probably less important. But a difference of 100x improvement is hugely noticeable.

Upgrading from one good SSD that is older to a newer model might give you 2x improvement to both random and sequantial speed. In such a case sequential is more noticeable.
People will still be upgrading though. They will just have to compete with older models like every other established industry.

btw, of interest the first j-micron SSDs were slightly faster in sequantial access but were 100x SLOWER then HDD in random writes.

 

[groberts101]

So many assumptions here.. and so little time to address them all.

@taltimir. That would only be useful for a basic generalization but is still not entirely true. And truth be told, GC is used for trim marked blocks on any Sandforce controlled drive as it typically just sets those previously trim-marked blocks aside for later recovery anyways. This is long known to be the case and many reviewers will also spell it out as well.

So, more correct to say that TRIM can and does make it more efficient for the controller to figure things out when cleaning is needed for on-the-fly recovery(such as would be the case for a completely dirty drive) since it improves wear leveling capabilities when the controller is in that "I need it now" type of state.

Fact is that every controller made these days is not going to be the same in the way that it chooses to use trim to recover blocks.. and just because the controller receives and marks those blocks as having been deleted at the filesystem level has absolutely squat to do with when the controller actually decides to erase and reallocate those blocks back into the fresh reserve pool.

Then we get into the way that various mfgrs are starting to use DRAM for the recovery and temporary mapping processes associated with it as it jockeys data around at the physical level(block write combining and partial block consolidation).. and those lines get even blurrier. Many ways to skin that cat these days.. which basically leaves us with the fact that absolutely no blanket statements can be made in regards to these processes any more.

@F1shF4t. The controller needs not have knowledge of the file system for garbage collection to work. The basic fundamental way that GC has always worked is via mapping comparisons of current logical data with current physical data stored on the SSD. Otherwise without TRIM?.. it could never figure these things out on its own. This is "typically" done moreso at idle time due to the overhead and processor(controller) overhead requirements, but there is a very recent trend to incorporate it during actual usage when the drive has reached full dirty states. The fact that this can and is done without trim availability should speak volumes as to these newer algorithms/more refined firmware coding of current gen SSD.

In reality, the bulk of this newer capability has more to do with the faster processing power(more cores) and increasing leverage of DRAM and(or larger amounts of physical space being set aside for the controllers overhead requirements) to get the job done without much in the way of performance loss during full dirty/on-the-fly recovery.

So, in a nutshell?.. much of what has been said here is very old news and not even close to being current by today’s standards. Now that mfgrs have come to the realization that PE/c(even with smaller nand architecture) is not such a huge concern?.. they are allowing much more aggressive on-the-fly recovery. None of which would be possible on a fast 6G SSD unless the controllers were fast enough to handle that requirement for increased overhead. Samsung specifically now uses 1 of their 3 available cores tasked just for the recovery process alone. Which again brings us back full circle to the fact that no blanket statements can be made these days.

Next gen controllers are already starting to arrive that will let us maintain speeds even when the drive is near completely full and still being hammered with consistent writes. And the most amazing thing about that?.. TRIM IS NOT REQUIRED TO DO IT.

That last capital letter statement just about says it all right there.

 

[groberts101]

RAID0 only improves on sequential performance, but does nothing for 4K random transfers, which is what's giving SSDs their superior responsiveness.

only the last part of that sentence is correct. 4k's, specifically the writes, do in fact go up as you add channels.

As a result of this.. multitasking is better with more drives added. I wouldn't even consider using 6 SSD's in R0 if that was not the case. Don't even need to run a benchmark to see and feel it either.

And that's not even taking into account the cumulative effects of ram caching as each new drive is added. Seeing is believing and many will never have a workload to ever see it anyways.. so to each his own ijn that respect.

 

[philipma1957]

You're thinking about the x25e, those guys were overprovisioned by what at the time seemed like a very large amount (96gb of nand on the 80gb ssd iirc).

The link is in the ssd's/storage section of the main page on Anandtech. You need to go back 7-8 pages to find it.

yeah thats the ticket I remember buying a pair of 32gb x25e's and running them as raid0 other then the price/size very nice ssds

 

[taltamir]

@taltimir. That would only be useful for a basic generalization but is still not entirely true. And truth be told, GC is used for trim marked blocks on any Sandforce controlled drive as it typically just sets those previously trim-marked blocks aside for later recovery anyways. This is long known to be the case and many reviewers will also spell it out as well.

read the links I posted

In the SF-1200 SandForce can only clean/recycle blocks at a rate of around 80MB/s. Typically this isn't an issue because you won't be in a situation where you're writing to a completely full drive (all user LBAs + spare area occupied with incompressible data). However if you do create an environment where all blocks have data in them (which can happen over time) and then attempt to write incompressible data, the SF-1200 will be limited by its block recycling path.

What you call GC is not GC at all. Earlier you described what happens with neither trim nor GC, and in this post you are calling the "block recycling path" GC, incorrectly.

You are simply confusing your terms.

only the last part of that sentence is correct. 4k's, specifically the writes, do in fact go up as you add channels.

Additional channels are significantly more efficient then RAID0 in improving your speed and handling extra writes.

RAID0 could increase your random performance... but only IF the RAID controller you are using was properly optimized to do so.