Plextor M5M (256GB) mSATA Review
by Kristian Vättö on April 17, 2013 10:20 AM ESTRandom Read/Write Speed
The four corners of SSD performance are as follows: random read, random write, sequential read and sequential write speed. Random accesses are generally small in size, while sequential accesses tend to be larger and thus we have the four Iometer tests we use in all of our reviews.
Our first test writes 4KB in a completely random pattern over an 8GB space of the drive to simulate the sort of random access that you'd see on an OS drive (even this is more stressful than a normal desktop user would see). I perform three concurrent IOs and run the test for 3 minutes. The results reported are in average MB/s over the entire time. We use both standard pseudo randomly generated data for each write as well as fully random data to show you both the maximum and minimum performance offered by SandForce based drives in these tests. The average performance of SF drives will likely be somewhere in between the two values for each drive you see in the graphs. For an understanding of why this matters, read our original SandForce article.
Random read performance is strong and nearly on par with the M5 Pro. However, at queue depth of 3 there is no substantial benefit from the increased parallelism with eight channels, hence the M5M is able to keep up.
Random write speed at lower queue depths has never been Plextor's biggest advantage and the M5M is no exception. The performance is not terrible but it's behind compared to many of the other today's high-end SSDs. However, at higher queue depths the performance raises to a level similar to other SSDs:
Sequential Read/Write Speed
To measure sequential performance I ran a 1 minute long 128KB sequential test over the entire span of the drive at a queue depth of 1. The results reported are in average MB/s over the entire test length.
Sequential write speed is slightly lower than what you get with all eight channels populated, but the difference isn't dramatic.
AS-SSD Incompressible Sequential Performance
The AS-SSD sequential benchmark uses incompressible data for all of its transfers. The result is a pretty big reduction in sequential write speed on SandForce based controllers.
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.