Up until now, we haven't seen storage giant Samsung devote much effort to the mSATA interface (at least, not in the aftermarket). That's changing though, and a quick trip to Newegg turns up retail packaging of the 840 EVO in capacities from 120 to 1000 GB. What's precipitating the new direction? An increasing breadth of devices employ the smaller format. There are laptops, sure. But more and more desktop motherboards come with mSATA slots as well. Then you have appliances like Drobo's Mini, which use mSATA-based solid-state storage for caching.
Apparently, Samsung determined that the time was right to make its move into mSATA (though enthusiasts fond of the company's desktop-oriented products might be muttering "it's about time"). We're promised that the wait was worth it. The 840 EVO platform boasts low power consumption and high density, both of which are important characteristics for mSATA-based drives that compromise little compared to the 2.5" form factor.

Another of Samsung's advantages is its control over every piece of the SSD puzzle. It manufactures the DRAM cache, the NAND flash, and the controller. Its engineers write the corresponding firmware and lay out the PCB all of those components drop onto. For as often as we talk about Samsung's vertical integration as a sign of its dominance in the space, the manifestation of this is control over supply. More than one SSD vendor has run into trouble sourcing parts for their drives, resulting in uncompetitive pricing at retail. Samsung doesn't have that problem.
With the 840 EVO's three-bit-per-cell NAND in 128 Gb densities, it's easier to achieve high capacities in small form factors. In fact, Samsung crams up to 1 TB onto the mSATA-based version of its 840 EVO, just like the 2.5" version. That's amazing, given the amount of PCB space available for a controller, cache, and NAND packages. The 840 EVO's 19 nm flash can be arranged in up to 16-die packages, meaning each of the four on-board emplacements host up to 256 GB. Amazing how that works out, right?

Samsung is shopping the mSATA-based 840 EVO family at four capacity levels: 120, 250, 500, and 1000 GB. There's a 750 GB version available in the 2.5" form factor you won't see make the transition, likely because the smaller market for mSATA storage doesn't justify its existence. Here's how the quartet of shipping 840 EVOs in mSATA trim break down, though:
| Samsung 840 EVO mSATA | 120 GB | 250 GB | 500 GB | 1000 GB |
|---|---|---|---|---|
| NAND | Samsung 19 nm Toggle-mode 2.0, 128 Gb Die, Three-Bit-Per-Cell Flash (TLC) | |||
| Controller | 400 MHz Samsung MEX, three-core ARM Cortex-R4 | |||
| Dies | 8 | 16 | 32 | 64 |
| Seqential Read / Write (MB/s) | 540/410 | 540 / 520 | ||
| Read / Write IOPS (QD=1) | 10,000 / 33,000 | |||
| Read / Write IOPS (QD=32) | 94,000 / 35,000 | 97,000 / 66,000 | 98,000 / 90,000 | 98,000 / 90,000 |
| Warranty | Three Years | |||
What this table doesn't reflect is the value-added Samsung Magician utility that comes bundled with the 840 EVOs. I've come to appreciate this inclusion as a fine piece of SSD management software. The latest version offers RAPID support to non-EVO drives like the 840 Pro. For those of you who missed our description of RAPID in Samsung 840 EVO SSD: Tested At 120, 250, 500, And 1000 GB:
RAPID is a software-based feature in Samsung's most recent build of Magician. Simply, it uses a gigabyte of system memory for caching hot data. Frequently-used applications are stored in RAM, ideally yielding much faster accesses when that data is needed over and over. Unlike other RAM-based caching solutions, RAPID keeps cached data persistent between reboots by writing information to the SSD itself.
In my initial look at RAPID in the 840 EVO review, I showed that the feature does genuinely improve performance across a broad range of client applications.

Back to the mSATA-based drive. The 120 GB model pictured has two NAND packages, the MEX controller, and a DRAM cache on one side of the PCB.

The other side has surface-mount components and a sticker. Samsung's 250, 500, and 1000 GB drives would have two additional packages under the sticker. They're simply not needed for the 120 GB model, though.
Let's head over to the test bench to see what these little drives can do...
Our consumer storage test bench is based on Intel's Z77 Platform Controller Hub paired with an Intel Core i5-2400 CPU. Intel's 6- and 7-series chipsets are virtually identical from a storage perspective. We're standardizing on older RST 10.6.1002 drivers for the foreseeable future.

Updates to the RST driver package occasionally result in subtle performance changes. They can also lead to some truly profound variance in scores and results as well, depending on the revision. Some versions flush writes more or less frequently. Others work better in RAID situations. Builds 11.2 and newer support TRIM in RAID as well. Regardless, results obtained with one revision may or may not be comparable to results obtained with another, so sticking with one version across all testing is mandatory.
| Test Hardware | |
|---|---|
| Processor | Intel Core i5-2400 (Sandy Bridge), 32 nm, 3.1 GHz, LGA 1155, 6 MB Shared L3, Turbo Boost Enabled |
| Motherboard | Gigabyte G1.Sniper M3 |
| Memory | G.Skill Ripjaws 8 GB (2 x 4 GB) DDR3-1866 @ DDR3-1333, 1.5 V |
| System Drive | Kingston HyperX 3K 240 GB, Firmware 5.02 |
| Drive(s) Under Test | Samsung 840 EVO mSATA 120 GB, Firmware: EXT41B6Q |
| Samsung 840 EVO mSATA 250 GB, Firmware: EXT41B6Q | |
| Samsung 840 EVO mSATA 500 GB, Firmware: EXT41B6Q | |
| Samsung 840 EVO mSATA 1000 GB, Firmware: EXT41B6Q | |
| SanDisk X210 256 GB, Firmware X210400 | |
| SanDisk X210 512 GB, Firmware X210400 | |
| Comparison Drives | Intel SSD 530 180 GB SATA 6Gb/s, Firmware: DC12 |
| Intel SSD 520 180 GB SATA 6Gb/s, Firmware: 400i | |
| Intel SSD 525 180 GB mSATA, Firmware: LLKi | |
| SanDisk A110 256 GB M.2 PCIe x2, Firmware: A200100 | |
| Silicon Motion SM226EN 128 GB SATA 6Gb/s, Firmware: M0709A | |
| Crucial M500 120 GB SATA 6Gb/s, Firmware: MU02 | |
| Crucial M500 240 GB SATA 6Gb/s, Firmware: MU02 | |
| Crucial M500 480 GB SATA 6Gb/s, Firmware: MU02 | |
| Crucial M500 960 GB SATA 6Gb/s, Firmware: MU02 | |
| Samsung 840 EVO 120 GB SATA 6Gb/s, Firmware: EXT0AB0Q | |
| Samsung 840 EVO 240 GB SATA 6Gb/s, Firmware: EXT0AB0Q | |
| Samsung 840 EVO 480 GB SATA 6Gb/s, Firmware: EXT0AB0Q | |
| Samsung 840 EVO 1 TB SATA 6Gb/s, Firmware: EXT0AB0Q | |
| SanDisk Ultra Plus 64 GB SATA 6Gb/s, Firmware: X211200 | |
| SanDisk Ultra Plus 128 GB SATA 6Gb/s, Firmware X211200 | |
| SanDisk Ultra Plus 256 GB SATA 6Gb/s, Firmware X211200 | |
| Samsung 840 Pro 256 GB SATA 6Gb/s, Firmware DXM04B0Q | |
| Samsung 840 Pro 128 GB SATA 6Gb/s, Firmware DXM04B0Q | |
| SanDisk Extreme II 120 GB, Firmware: R1311 | |
| SanDisk Extreme II 240 GB, Firmware: R1311 | |
| SanDisk Extreme II 480 GB, Firmware: R1311 | |
| Seagate 600 SSD 240 GB SATA 6Gb/s, Firmware: B660 | |
| Intel SSD 525 30 GB mSATA 6Gb/s, Firmware LLKi | |
| Intel SSD 525 60 GB mSATA 6Gb/s, Firmware LLKi | |
| Intel SSD 525 120 GB mSATA 6Gb/s, Firmware LLKi | |
| Intel SSD 525 180 GB mSATA 6Gb/s, Firmware LLKi | |
| Intel SSD 525 240 GB mSATA 6Gb/s, Firmware LLKi | |
| Intel SSD 335 240 GB SATA 6Gb/s, Firmware: 335s | |
| Intel SSD 510 250 GB SATA 6Gb/s, Firmware: PWG2 | |
| OCZ Vertex 3.20 240 GB SATA 6Gb/s, Firmware: 2.25 | |
| OCZ Vector 256 GB SATA 6Gb/s, Firmware: 2.0 | |
| Samsung 830 512 GB SATA 6Gb/s, Firmware: CXMO3B1Q | |
| Crucial m4 256 GB SATA 6Gb/s Firmware: 000F | |
| Plextor M5 Pro 256 GB SATA 6Gb/s Firmware: 1.02 | |
| Corsair Neutron GTX 240 GB SATA 6Gb/s, Firmware: M206 | |
| Graphics | MSI Cyclone GTX 460 1 GB |
| Power Supply | Seasonic X-650, 650 W 80 PLUS Gold |
| Chassis | Lian Li Pitstop |
| RAID | LSI 9266-8i PCIe x8, FastPath and CacheCade AFK |
| System Software and Drivers | |
| Operating System | Windows 7 x64 Ultimate |
| DirectX | DirectX 11 |
| Drivers | Graphics: Nvidia 314.07 RST: 10.6.1002 IMEI: 7.1.21.1124 Generic AHCI: MSAHCI.SYS |
| Benchmarks | |
|---|---|
| Tom's Hardware Storage Bench v1.0 | Trace-Based |
| Iometer 1.1.0 | # Workers = 1, 4 KB Random: LBA=16 GB, varying QDs, 128 KB Sequential, 8 GB LBA Precondition, Exponential QD Scaling |
| PCMark 7 | Secondary Storage Suite |
| PCM Vantage | Storage Suite |
Fantastic sequential read and write performance is a trademark of modern SSDs. To measure it, we use incompressible data over a 16 GB LBA space, and then test at queue depths from one to 16. We're reporting these numbers in binary (where 1 KB equals 1024) instead of decimal numbers (where 1 KB is 1000 bytes). When necessary, we're also limiting the scale of the chart to enhance readability.
128 KB Sequential Read
Samsung's four mSATA-based 840 EVOs top 500 MB/s with just two outstanding commands. Read performance, despite three-bit-per-cell NAND, remains a strength. These are the kind of numbers we'd expect from the 840 Pro, but it's more surprising to see coming from the company's 840 and 840 EVO. Still, with sequential reads, we'd be concerned if performance wasn't this high.
128 KB Sequential Write
Sequential writes are where we see the benefit of more dies. As capacity shifts from 120 to 1000 GB, write performance increases substantially. Admittedly, Samsung's Turbo Write technology does affect the outcome by using some of the MLC as emulated single-level cell flash. And of course, the larger models have more of this faster space at their disposal. Because this is how we test, the results end up quite favorable for Samsung. But expect minimum performance (what you'll see once the cache limits are surpassed) to be a good deal lower.
Here's a break-down of the maximum observed 128 KB sequential read and write performance with Iometer:
The 840 EVO mSATA drives manage respectable finishes in our sequential performance testing. Demonstrating very similar read speeds, positioning in this chart comes down to the results of our write testing. Not only does write performance scale with the number of dies, but Samsung's Turbo Write cache size increases with capacity, too. That means the 1000 GB model with 12 GB of cache is able to post particularly impressive write numbers, exceeding 500 MB/s.
Even the modest 120 GB drive, with just eight die, achieves more than 200 MB/s in our write benchmark. Once the Turbo Write cache is filled, you'll see the 120 GB 840 EVO drop to 130 MB/s or so. And in that product's case, a scant 3 GB of cache fills up a lot more quickly. Even still, the benefit is tangible in real-world measures of performance.
Although Turbo Write complicates our results, it's a solid technology. Moreover, it's now one of several SLC emulation systems in use. SanDisk's nCache is one of the originals, but Toshiba, OCZ, and now Samsung employ mechanisms that are not entirely dissimilar. As you can see, benchmarking and explaining results gets tougher. But their utility does translate into real-world performance improvements. Particularly when you're talking about the smaller drives equipped with fewer dies, the speed-up is meaningful.
We turn to Iometer as our synthetic metric of choice for testing 4 KB random performance. Technically, "random" translates to a consecutive access that occurs more than one sector away. On a mechanical hard disk, this can lead to significant latencies that hammer performance. Spinning media simply handles sequential accesses much better than random ones, since the heads don't have to be physically repositioned. With SSDs, the random/sequential access distinction is much less relevant. Data are put wherever the controller wants it, so the idea that the operating system sees one piece of information next to another is mostly just an illusion.
4 KB Random Reads
Testing the performance of SSDs often emphasizes 4 KB random reads, and for good reason. Most system accesses are both small and random. Moreover, read performance is arguably more important than writes when you're talking about typical client workloads.
The four 840 EVOs return similar small random read performance figures across our range of outstanding comments. Again, it's worth mentioning that this discipline typically isn't dependent on die configuration. As with the sequential read numbers on the previous page, random reads prove similar. Truth be told, there are a few companies inwardly jealous of the read speed Samsung's able to achieve with TLC NAND.
4 KB Random Writes
Random write performance is also important. Early SSDs didn't do well in this discipline, seizing up even in light workloads. Newer SSDs wield more than 100x the performance of drives from 2007, though we also recognize that there's a point of diminishing returns in desktop environments.

Nutty, right? There are a couple variables at work that result in this disorderly chart. First, Turbo Write comes back into play, increasing performance, but messing with our Iometer-generated numbers. Since methodology only makes sense when it's consistent, going out of our way to change the benchmark to illustrate higher or lower performance wouldn't make sense.
The 120 GB model's Turbo Write cache always gets filled first, since it's only effectively 3 GB in size. If the cache can't flush to the drive faster than the data coming in, performance drops back to unaccelerated levels. Meanwhile, the 1000 GB model sets aside 36 GB, which turns into 12 GB of emulated SLC flash. Naturally, it benefits from caching quite a bit longer.
In any case, this is a big jump over the original 840. In real life, bursty random writes will almost entirely hit the cache in desktop workloads. SanDisk, Samsung, and Toshiba are on the right track with this stuff; approaching 90,000 4 KB write IOPS with triple-level cell NAND is a good indicator of that.
Random Performance Over Time
My saturation test consists of writing to each drive for a specific duration with a defined workload. Technically, it's an enterprise-class benchmark, where the entire LBA space of the SSD is utilized by a random write at high queue depths.

Here's 12 hours of a 4 KB write with 32 outstanding commands. First, we secure erase each drive. Then we apply the 4 KB write load, showing the average IOPS for each minute (except for the last 20 minutes, where we zoom in and show you one-second average increments).
After the first drive fill, performance drops off fast, since the SSD no longer has free blocks to write to. Instead, they have to be erased prior to subsequent writes. The 840 EVOs are interesting in that performance plummets early on, well before any of them are filled up. In this case, the first peaks are a result of Turbo Write's awesome potential. But those numbers only last as long as there is room in the cache. As soon as that gets exceeded, throughput drops to the second level, reflecting Samsung's TLC flash. Then, once the entire drive is full, the SSD shifts into steady state.
Yes, the drive probably is trying to flush data to the non-emulated space as it fills. But things happen quickly when performance is so high. Just look at the 120 GB model's trace, which averages 33,500 during the first 17 minutes of testing. The first minute is much higher than subsequent readings because, at 33,500 IOPS (130 MB/s), it only takes 23 seconds to fill the 3 GB cache. Performance is averaged over that minute, and as a result, that first minute looks a lot faster.
This stuff is fascinating, if you're into it like I am.
Here's a break-down of the maximum observed 4 KB sequential read and write performance with Iometer. The order the drives appear in our chart is determined by maximum combined read and write performance.
The 500 GB 840 EVO takes third place when we look at maximum 4 KB read and write performance (attributable to Turbo Write's effect on write performance, no doubt). There's a lot of variance when it comes to measuring the technology's impact though, so just imagine the three largest 840 EVOs closer together. They're more similar than this chart suggests.
Storage Bench v1.0 (Background Info)
Our Storage Bench incorporates all of the I/O from a trace recorded over two weeks. The process of replaying this sequence to capture performance gives us a bunch of numbers that aren't really intuitive at first glance. Most idle time gets expunged, leaving only the time that each benchmarked drive is actually busy working on host commands. So, by taking the ratio of that busy time and the the amount of data exchanged during the trace, we arrive at an average data rate (in MB/s) metric we can use to compare drives.
It's not quite a perfect system. The original trace captures the TRIM command in transit, but since the trace is played on a drive without a file system, TRIM wouldn't work even if it were sent during the trace replay (which, sadly, it isn't). Still, trace testing is a great way to capture periods of actual storage activity, a great companion to synthetic testing like Iometer.
Incompressible Data and Storage Bench v1.0
Also worth noting is the fact that our trace testing pushes incompressible data through the system's buffers to the drive getting benchmarked. So, when the trace replay plays back write activity, it's writing largely incompressible data. If we run our storage bench on a SandForce-based SSD, we can monitor the SMART attributes for a bit more insight.
| Mushkin Chronos Deluxe 120 GB SMART Attributes | RAW Value Increase |
|---|---|
| #242 Host Reads (in GB) | 84 GB |
| #241 Host Writes (in GB) | 142 GB |
| #233 Compressed NAND Writes (in GB) | 149 GB |
Host reads are greatly outstripped by host writes to be sure. That's all baked into the trace. But with SandForce's inline deduplication/compression, you'd expect that the amount of information written to flash would be less than the host writes (unless the data is mostly incompressible, of course). For every 1 GB the host asked to be written, Mushkin's drive is forced to write 1.05 GB.
If our trace replay was just writing easy-to-compress zeros out of the buffer, we'd see writes to NAND as a fraction of host writes. This puts the tested drives on a more equal footing, regardless of the controller's ability to compress data on the fly.
Average Data Rate
The Storage Bench trace generates more than 140 GB worth of writes during testing. Obviously, this tends to penalize drives smaller than 180 GB and reward those with more than 256 GB of capacity.

Each of Samsung's mSATA-based drives is pitted against a 2.5" 840 EVO equivalent, which I'm highlighting in red. The 120 and 250 GB models yield almost identical results using both interfaces. But that changes as we ascend the chart; the 500 and 1000 GB mSATA-based 840 EVOs fall behind the 2.5" drives. It's possible that firmware plays a role, but I suspect that the work needed to enable high capacities on mSATA has something to do with it.
Service Times
Beyond the average data rate reported on the previous page, there's even more information we can collect from Tom's Hardware's Storage Bench. For instance, mean (average) service times show what responsiveness is like on an average I/O during the trace.
It would be difficult to graph the 10+ million I/Os that make up our test, so looking at the average time to service an I/O makes more sense. For a more nuanced idea of what's transpiring during the trace, we plot mean service times for reads against writes. That way, drives with better latency show up closer to the origin; lower numbers are better.
Write latency is simply the total time it takes an input or output operation to be issued by the host operating system, travel to the storage subsystem, commit to the storage device, and have the drive acknowledge the operation. Read latency is similar. The operating system asks the storage device for data stored in a certain location, the SSD reads that information, and then it's sent to the host. Modern computers are fast and SSDs are zippy, but there's still a significant amount of latency involved in a storage transaction.
Samsung's 840 EVOs fare well, regardless of interface. Once again, the 2.5" form factor is in red, while the mSATA-based models sport a fetching shade of blue.
Despite a slight increase in read latency, the 120 GB mSATA-based 840 EVO trounces the 2.5" equivalent in write latency. Both break the 120 GB M500 like a shotgun, though.
The 250 GB model demonstrates the same behavior, while the two larger mSATA-based SSDs fall just behind their 2.5" counterparts. Again, I suspect this is attributable to shoehorning 32 and 64 dies into four packages. The 2.5" 840 EVOs employ a different configuration. It's hard to identify the issue definitively, though. After all, the SATA drives are still running pre-launch firmware, while the mSATA-based SSDs employ a different version.

We can examine the results more closely by breaking out the mean read service times. As we already know, the smaller two mSATA-based 840 EVOs are close to the 2.5" implementations, while the larger two mSATA-capable models fall behind the high-capacity SATA-equipped SSDs.

Mean write service times are nothing short of excellent considering how long it takes to program triple-level cell flash. As lithographies shrink, NAND becomes ever more error-prone, taking longer to erase and re-program. That factor pales in comparison to the toll imposed by cramming three bits into one cell, though. That the 840 EVOs yield lower mean service times than some high-end desktop-oriented SSDs is more than a little awesome.
Samsung's 120 GB drive isn't exactly best-of-breed. But it only uses eight dies, so that's still pretty impressive. In comparison, Crucial's 120 GB M500 fares worse, and that's with two-bit-per-cell MLC. No doubt, some of its performance deficit can be blamed on a more conservative approach to storage that employs a parity scheme, facilitating recovery should part of a NAND die fail.
Futuremark's PCMark 7: Secondary Storage Suite
PCMark 7 uses the same trace-based technology as our Storage Bench v1.0 for its storage suite testing. It employs a geometric mean scoring system to generate a composite, so we end up with PCMarks instead of a megabytes per second. One-thousand points separate the top and bottom, but that encompasses a far larger difference than the score alone indicates.
This test is a big improvement over the older PCMark Vantage, at least for SSD benchmarking. The storage suite is comprised of several small traces. At the end, the geometric mean of those scores is scaled with a number representing the test system's speed. The scores generated are much different from PCMark Vantage, and many manufacturers are predisposed to dislike it for that reason. It's hard to figure out how PCMark 7 "works" because it uses a sliding scale to generate scores. Still, it represents one of the best canned benchmarks for storage, and if nothing else, it helps reinforce the idea that the differences in modern SSD performance don't necessarily amount to a better user experience in average consumer workloads.

Intentionally gamed through optimized firmware, or simply as a side-effect of excellent all-around performance, the 840 EVO drives excel in PCMark 7. Samsung's drives take the top six spots, and four of them are 840 EVOs (the 500 and 1000 GB mSATA-based drives finish behind the SATA-attached models).
Just remember that the actual delta between the fastest and slowest SSDs is still very small. In fact, we're starting the scale at 80% just to make it easier to identify differences. At full scale, there's only a sliver distinguishing one repository from the next.
Futuremark's PCMark Vantage: Hard Drive Suite
PCMark's Vantage isn't the paragon of SSD testing, mainly because it's old and wasn't designed for the massive performance solid-state technology enables. Intended to exploit the new features in Windows Vista, Vantage was at the forefront of consumer storage benching back in the day. Vantage works by taking the geometric mean of composite storage scores and then scaling them a lot like PCMark 7 does. But in Vantage's case, this scaling is achieved by arbitrarily multiplying the geometric sub-score mean by 214.65. That scaling factor is supposed to represent an average test system of the day (a system that's now close to a decade behind the times). PCMark 7 improves on this by creating a unique system-dependent scaling factor and newer trace technology.
Why bother including this metric, then? A lot of folks prefer Vantage in spite of or because of the cartoonish scores and widespread adoption. That, and the fact that most every manufacturer uses the aged benchmark in box specs and reviewer-specific guidelines. In fairness, Vantage's Hard Drive suite wasn't designed with SSDs in mind, and is actually quite good as pointing out which 5400 RPM mechanical disk might be preferable.

In a reversal, the 250 and 500 GB mSATA-based 840 EVOs appear in front of their SATA-based relatives. Somewhat shockingly, the 1000 GB mSATA-attached model falls to the bottom. Like, straight next-to-last territory. Is something wrong? My guess is no.
Despite numerous tests on several systems, I kept coming up with similar performance on the heavily 4 KB-dependent Vantage HDD Suite. Again, I think this is likely due to some issue with NAND configuration on the 1000 GB model. Cramming 1024 GB of flash on an mSATA PCB without relying on a daughter board is impressive, though likely not without challenges.
Microsoft's Robocopy, a CLI directory replication command, gradually replaced the older xcopy. It's multi-threaded, has a ton of options, and generally outperforms vanilla Windows copy operations. Best of all, it's built right in to Redmond's operating system. Especially useful for network copy operations and backups, Robocopy doesn't stop to ask you one hundred questions while it copies over your music collection, either.
The reality of benchmarking file copy performance is that you need something fast to move data from and fast hardware to move it to. This is most important with SSDs. It doesn't matter if your drive can write sequentially at 500 MB/s if the source files are hosted on a USB 2.0-attached external hard drive. We're copying our test files from an Intel SSD DC S3700 to the drives in the chart below, taking source speed out of the equation (mostly). Moving to faster storage would increase the faster test disks' ultimate file copy performance. It begs the question though -- what is the point? Most users copying data from one source to another (in this case, a SSD) won't have the benefit of copying from a SSD RAID array or PCIe-based solid state storage, so relying on just one SSD as the source gives us the best case average.
There are 9065 files comprising the 16.2 GB payload. Some of the files are huge (up to 2 GB), while others are best described as tiny. On average, that's around 1.8 MB per file. The files are a mix of music, program, pictures, and random file types.
It's fair to say that this chart would look much different if we were copying from a hard drive to a SSD. Even if the disk drive's sequential throughput wasn't a bottleneck, it'd still choke on the smaller files.

We aren't presented with many surprises. The big SSDs are fast; the little ones are still pretty quick. Samsung's 500 and 1000 GB models take second and third place, respectively. The 120 and 250 GB units are more modest in their performances, though still quite a bit faster than their 840 progenitors, despite the transition from 2x nm 64 Gb dies to 19 nm 128 Gb dies.
Idle Power Consumption
Idle consumption is the most important power metric for consumer and client SSDs. After all, solid-state drives complete host commands quickly, and then drop back down to idle. Aside from the occasional background garbage collection, a modern SSD spends most of its life doing very little. Enterprise-oriented drives are more frequently used at full tilt, making their idle power numbers less relevant. But this just isn't the case on the desktop, where the demands of client and consumer computing leave most SSDs sitting on their hands for long stretches of time.
Active idle power numbers are critical, especially when it comes to their impact on mobile platforms. Idle means different things on different systems, though. Pretty much every drive we're testing is capable of one or more low-power states, up to and including DevSleep. That last feature is a part of the SATA 3.2 host specification. And while it requires a capable SSD and a compatible platform, enabling it takes power consumption down to a very small number.
Samsung's newest drives really throw down the gauntlet when it comes to idle power measurements. The mSATA-based SSDs are thriftiest of all. Sure, the 1000 GB model does use almost 50% more power at idle than the three lower capacities, but that's still less than three-tenths of a watt. Each of the smaller drives manage .21 W at active idle.
PCMark 7 Average Power Consumption
If we log power consumption through a workload, even a relatively heavy one, we see that average use is still pretty close to the idle numbers. Maximum power may spike fiercely, but the usage seen during a PCMark 7 run is pretty light. You can see the drives fall back down to the idle "floor" between peaks of varying intensity.

Our average PCMark 7 power numbers tell a similar story, with the 1000 GB drive using significantly more power than the 120, 250, and 500 GB models. The log data shows what's happening in far greater detail. Behold!

See? The three smaller units are exceedingly similar, though with higher corresponding peak figures. The 1000 GB demonstrates significantly different characteristics, with considerably higher max use. Even when it comes off the peaks, though, it's still using more juice than the rest of the field.
As we already know, idle power is much higher comparatively, so this all makes sense. Whatever Samsung had to do to make the 1000 GB mSATA-based model possible, there's clearly something unique going on with it.
Maximum Observed Power Consumption
Triple-level cell NAND requires more power than two-bit-per-cell flash. And yet, the two top spots in this chart are dominated by Samsung's 120 GB 840 EVO in 2.5" and mSATA trim. The 1000 GB version lands mid-pack, which is still quite good for a massive flash-based repository larger than the 120, 250, and 500 GB models put together.
Finally, I want to introduce a new test I've been working on using JEDEC's 218A consumer workload trace to create a TRIM benchmark. It's not a neatly-packaged little utility you can run at home. Rather, this is a test scripted in ULINK's DriveMaster 2012 software and hardware suite.
DriveMaster is used by most SSD manufacturers to create and perform specific metrics. It's currently the only commercial product that can create the scenarios needed to validate TCG Opal 2 security, but it's almost unlimited in potential applications. There are various hardware components associated with the platform, such as a SATA/SAS power hub that allows the benchmarked drive to be power-cycled independently of the platform. Much of the benefit tied to a solution like DriveMaster is its ability to diagnose bugs, ensure compatibility, and issue low-level commands. In short, it's very handy for the companies actually building SSDs. And if off-the-shelf scripts don't do it for you, make your own. There's a steep learning curve, but the C-like environment and command documentation gives you a fighting chance.
This product also gives us some new ways to explore performance. Testing the TRIM command is just the first example of how we'll be using ULINK's contribution to the Tom's Hardware benchmark suite.

The suite ships with some built-in scripts, but also contains its own scripting language for extensibility and customization. This particular test uses JEDEC's published master trace of consumer I/O activity (similar to our Tom's Hardware Storage Bench trace). The read commands are removed from the trace, leaving write, flush, and TRIM commands. After secure erasure and writing preparatory data, the test commences. The trace is played against the drive four times using NCQ with and without TRIM, and DMA with and without TRIM. IOPS are measured and averaged every 100,000 commands.
On a 256 GB drive, each iteration writes close to 800 GB of data, so running the JEDEC TRIM test suite once on a 256 GB SSD generates almost 3.2 TB of mostly random writes (it's 75% random and 25% sequential). By the end of each run, over 37 million write commands are issued. If that sounds like a lot of storage traffic, it is.
The first two tests employ DMA to access the storage, while the last two use Native Command Queuing. Since most folks don't use DMA with SSDs (aside from some legacy or industrial applications) we don't concern ourselves with those. It can take up to 96 hours to run one drive through all four runs, though faster drives can cut the time in half, roughly. Because so much information is being written to an already-full SSD (the drive is filled before each test, and then close to 800 GB are written per iteration), SSDs that perform better under heavy load fare best. Without TRIM, on-the-fly garbage collection becomes a big contributor to high IOPS. With TRIM, 13% of space gets TRIM'ed, leaving more room for the controller to use for maintenance operations.
TRIM Testing
Here's the chart derived from our DriveMaster JEDEC TRIM test data. We have the 256 GB SanDisk X210, Samsung's venerable 840 Pro at 256 GB, Crucial's more mainstream M500 (240 GB), and the 250 GB 840 EVO. Each device's NCQ-based test is plotted. The solid line represents average IOPS every 100,000 commands, but without TRIM. The hashed line represents performance every 100,000 commands with TRIM. In each case, the workload is mixed in with tons of small, random writes.

Unlike the other (admittedly small) samples, the 840 EVO gets a measurable bump with TRIM enabled. In fact, Samsung's mSATA-based drive shows the largest performance increase from TRIM. The 840 Pro speeds up as well, but comparatively, the 840 EVO is quite impressive.
Last summer, we got our hands on Samsung's 840 EVO and tested, and tested, and tested. There were some new technologies in play, some of which had a big impact on the benchmarks we were running. But once we wrapped our heads around the performance numbers, we conceded that the 840 EVO was a compelling piece of hardware, triple-level cell NAND and all.
The drive's performance was about as high as we could expect, given a SATA 6Gb/s interface. And now that Samsung has eDrive/TCG Opal 2.0 support working, security coverage is impeccable as well. Add RAPID caching software on top of the firmware's Turbo Write technology, and the performance story only got better. We concluded our coverage with a look at Samsung's comprehensive SSD management software, which I still think is the most feature-packed package of its kind. As a bonus, Samsung includes its own cloning utility (though I've had mixed results with that). By the end of our review, we had found a lot to like. The 840 EVO was (and still is) an impressive mainstream offering. But what really pushed us over the edge was availability of a 1 TB model, which joined Crucial's M500 as an affordable 1 TB-class option for enthusiasts.

Now that Samsung is putting its 840 EVO platform to work on the mSATA interface (even the improbable 1000 GB model), we see more of the same. This is good news for the growing crop of devices able to take mSATA-based SSDs to save space. Once upon a time, compatible devices were smaller, slower, and a lot more expensive. But we just saw that you don't have to give anything up in terms of capacity or performance. There is still a price premium in play, but the smaller form factor offers certain other benefits to help compensate. And you'll definitely come in under the $1/GB mark.
Sure, the retail mSATA market is fairly nichey. But Samsung's competition should at least be nervous. This company has a track record of disrupting the markets it enters; now that it's focusing attention on smaller form factors with enthusiast-class hardware, it's only a matter of time before we start seeing M.2-based offerings as well.
The 1 TB 840 EVO in mSATA trim is a decidedly important component, given the lack of high-capacity options in that small form factor. Only a handful of 512 GB-class mSATA-based SSDs exist, and good luck finding anything larger. Not only does Samsung push everything that's good about its 840 EVO into a compact form factor, but it does so using four NAND packages and excellent power consumption characteristics.
I actually think that the 500 GB model is even more attractive. It's performance is equal to or better than the 1 TB SSD, and of course it's more affordable. The 256 GB version takes a small step back in the benchmark charts, but it remains in distinguished company. Even the disadvantaged 120 GB drive handles itself as well as can be expected. It's at least among the other mainstream 128 GB-class offerings (with generally-better read performance).

Understandably, the high-capacity 840 EVOs are feathers in Samsung's hat. The more pedestrian models are arguably more meaningful, since they're what most of us can afford. On those SSDs, Turbo Write kicks in to help counter the limitations of triple-level cell NAND. Read speeds match almost any other SATA 6Gb/s-capable drive out there, and the emulated SLC cache helps augment write performance, too.
After a page of reflecting on the 840 EVO's positive qualities, it's worth mentioning that there isn't much critical we can say. Crucial's M500 is the most relevant contender, and where the M500 gives up some performance, a bit of capacity, and some fancy extras, it also wields NAND redundancy and more robust power resiliency. The two competing line-ups offer accelerated eDrive and TCG Opal 2.0 security, while the M500 technically benefits from two-bit-per-cell NAND.
It's a tough choice that only gets easier if you're looking at the top capacity point; Crucial doesn't have its 960 GB M500 available in mSATA form yet. We suspect storage enthusiasts will go around in circles trying to pick a favorite until something shiner shows up. What we can say is that your mSATA-based choices continue getting better. Really, Samsung's 840 EVO is a great representation of the interface done right. It's worthy of consideration as you look to populate the tiny slot on your notebook or small form factor desktop, to be sure.







