Plextor M5M (256GB) mSATA Review
by Kristian Vättö on April 17, 2013 10:20 AM EST
We have lately seen SSD manufacturers paying more and more attention to the retail mSATA SSD market. For long the retail mSATA SSD market was controlled by only a few players: Crucial, ADATA and Mushkin were the only ones with widely available models. Intel also had a few models available for retail but those were all rather small and outdated (SATA 3Gbps and mainly aimed for caching with Intel Smart Response Technology). In the OEM market, you have mSATA SSDs from major brands, such as Samsung and Toshiba, but unfortunately many manufacturers have decided not to push their mSATA SSDs for the retail market.
Like I've said before, the market for retail mSATA SSDs isn't exactly alluring but on the other hand, the market can't grow if the products available are not competitive. With only a few manufacturers playing in the field, it was clear that there wasn't enough competition, especially when compared to the 2.5" SATA market. A short while ago, Intel brought the SSD 525 and some very needed presence from a big SSD manufacturer to the mSATA retail market. Now we have another player, Plextor, joining the chorus.
Plextor showcased their M5M mSATA SSD already at CES but the actual release took place mid-February. Architecturally the M5M is similar to Plextor's M5 Pro Xtreme: Both use Marvell's 88SS9187 controller, 19nm Toshiba NAND and Plextor's custom firmware. The only substantial difference is four NAND packages instead of 8/16, which is due to mSATA's space constraints.
| M5M (256GB) | M5 Pro Xtreme (256GB) | |
| Sequential Read | 540MB/s | 540MB/s |
| Sequential Write | 430MB/s | 460MB/s |
| 4KB Random Read | 80K IOPS | 100K IOPS |
| 4KB Random Write | 76K IOPS | 86K IOPS |
Performance wise the M5M is slightly behind the M5 Pro Xtreme but given the limited NAND channels, the performance is very good for an mSATA SSD. Below are the complete specs for each capacity of the M5M:
| Plextor M5M mSATA Specifications | |||
| Capacity | 64GB | 128GB | 256GB |
| Controller | Marvell 88SS9187 | ||
| NAND | Toshiba 19nm Toggle-Mode MLC | ||
| Cache (DDR3) | 128MB | 256MB | 512MB |
| Sequential Read | 540MB/s | 540MB/s | 540MB/s |
| Sequential Write | 160MB/s | 320MB/s | 430MB/s |
| 4KB Random Read | 73K IOPS | 80K IOPS | 79K IOPS |
| 4KB Random Write | 42K IOPS | 76K IOPS | 77K IOPS |
| Warranty | 3 years | ||
The M5M tops out at 256GB because that's the maximum capacity that you can currently achieve with four NAND packages and 8GB die (4x8x8GB). It's possible that we'll see a 512GB model later once 16GB per die NAND is more widely available.
Similar to Plextor's other SSDs, the M5M uses DRAM from Nanya and NAND from Toshiba. There's a 512MB DDR3-1333 chips acting as a cache, which is coupled by four 64GB (8x 8GB die) MLC NAND packages. The small chip you're seeing is a 85MHz 8Mb serial NOR flash chip from Macronix, which is used to house the drive's firmware. This isn't anything new as Plextor has always used NOR flash to store the firmware, but the package is just different to meet mSATA dimension requirements.
Removing the sticker reveals the heart of the M5M: The Marvell 88SS9187.
I discovered a weird bug during the testing of the M5M. Every once in a while, the drive would drop to SATA 3Gbps speeds (~220MB/s in Iometer) after a secure erase and the performance wouldn't recover until another secure erase command was issued. I couldn't find any logic behind the bug as the slow downs were totally random; sometimes the drive went through a dozen cycles (secure erase, test, repeat) while on some occasions the issue occurred after nearly every secure erase. At first I thought it was my mSATA to SATA 6Gbps adapter, so I asked Plextor for a new adapter and sample to make sure we were not dealing with defective hardware. However, the bug persisted. I've noticed similar behavior in the M5 Pro Xtreme (though not in the original M5 Pro) which is why I'm guessing the bug is firmware related (hardware issue would be much harder to fix).
To date, Plextor has not been able to reproduce the bug, although I'm still working with their engineers in order to repeat our testing methodology as closely as possible. I don't think the bug will be a huge issue for most buyers as there's rarely a need to secure erase the drive but it's still something to keep in mind when looking at the M5M.
Test System
| CPU | Intel Core i5-2500K running at 3.3GHz (Turbo and EIST enabled) |
| Motherboard | AsRock Z68 Pro3 |
| Chipset | Intel Z68 |
| Chipset Drivers | Intel 9.1.1.1015 + Intel RST 10.2 |
| Memory | G.Skill RipjawsX DDR3-1600 2 x 4GB (9-9-9-24) |
| Video Card |
XFX AMD Radeon HD 6850 XXX (800MHz core clock; 4.2GHz GDDR5 effective) |
| Video Drivers | AMD Catalyst 10.1 |
| Desktop Resolution | 1920 x 1080 |
| OS | Windows 7 x64 |
Facebook
Twitter
RSS
36 Comments
View All Comments
kmmatney - Wednesday, April 17, 2013 - link
" I strongly recommend having at least 25% free space with the M5M. The more you fill the drive, the more likely it is that you'll face inconsistent performance."Would this really effect the average user? Do you let the drives idle long enough so the normal garbage collection can kick in?
msahni - Wednesday, April 17, 2013 - link
Hi there,First of all Kristian thanks for the reviews. You've finally answered my queries about the best mSATA SSD to get. (from the Intel 525 review)
Could you please advise what is the best method to leave the 25% free space on the drive for over provisioning to enhance the performance.
Cheers....
Minion4Hire - Wednesday, April 17, 2013 - link
Anand answered that in another article. I believe you are supposed to shrink the partition, create a second partition out of the unallocated space, then delete the new partition. The act of deleting the partition brings the OS to TRIM that portion of the drive freeing it up for use as spare area. And since you won't be writing to it any more it is permanently spare area (well, unless you repartition or something)xdrol - Wednesday, April 17, 2013 - link
Actually, Windows does not trim when you delete a partition, rather when you create a new one.Hrel - Wednesday, April 17, 2013 - link
I have wondered for a long time if the extra free space is really necessary. Home users aren't benchmarking, drives are mostly idle. Not often do you transfer 100GB at a time or install programs.JellyRoll - Wednesday, April 17, 2013 - link
Unrealistic workloads for a consumer environment result in unrealistic test results. How many consumer notebooks or laptops, hell even enterprise mobile devices, will be subjected to this type of load? Answer: Zero.Even in a consumer desktop this is NEVER going to happen.
JPForums - Thursday, April 18, 2013 - link
It was stated a long time ago at Anandtech that their testing was harsher than typical consumer loads for the express purpose of separating the field. Under typical consumer workloads, there is practically no difference between modern drives. I don't know how many times I've read that any SSD is a significant step up from an HDD. It has pretty much been a standing assumption since the old jMicron controllers left the market. However, more information is required for those that need (or think they need) the performance to handle heavier workloads.Personally, everything else being equal, I'd rather have the drive that performs better/more consistently, even if it is only in workloads I never see. I don't think Kristian is trying to pull the wool over your eyes. He simply gives the readers here enough credit to make up their own mind about the level of performance they need.
Kristian Vättö - Wednesday, April 17, 2013 - link
If the drive is nearly full and there's no extra OP, then it's possible that even normal (but slightly larger/heavier, like app installation) usage will cause the performance to become inconsistent which will affect the overall performance (average IOPS will go down). Performance will of course recover with idle time but the hit in performance has already been experienced.JellyRoll - Wednesday, April 17, 2013 - link
Running a simple trace of an application install will show that this is not an accurate statement. This testing also does not benefit from TRIM because there is no filesystem during the test. This ends up making an overly-negative portrayal.JPForums - Thursday, April 18, 2013 - link
Which test in particular are you referring to that has no access to TRIM, that otherwise would?As far as application traces go, I can confirm Kristian's statement is accurate on both a Corsair Force GT 120GB and a Crucial M4 128GB. Performance drops appreciably when installing programs with a large number of small files (or copying a large number of small files I.E. Libraries). As an aside, it can also tank the performance of Xilinx ISE, which is typically limited by memory bandwidth and single threaded CPU performance.