The Plextor M3 (256GB) Review
by Kristian Vättö on April 5, 2012 3:05 AM ESTIntroduction
Plextor as a brand has been around for quite a while, but most of our long-time readers are likely more familiar with the name as a purveyor of optical drives (especially 8-15 years back when optical drive performance actually mattered). For our younger audience, the name may be a relative unknown. However, Plextor is not a newcomer in the SSD market or component world in general.
Plextor’s history dates back almost a century as it is a subsidiary of Shinano Kenshi Corporation, which was founded in 1918. The actual Plextor brand was founded in 1990 and Plextor mainly manufactured optical disc drives in the 90s. (For a fun blast from the past, you can still find our old Plextor drive reviews.) Plextor’s product lineup has always been and is still heavily optical drive orientated but in March 2010, Plextor revealed their first SSD lineup: The PX-64M1s and PX-128M1S.
About a year later, Plextor released their second generation SSDs: the M2 Series. It was among the first consumer SATA 6Gb/s drives and was based on Marvell’s 88SS9174-BJP2 controller, which is the same controller used in Crucial RealSSD C300. Plextor is now on its third generation of SSDs and we finally have the chance to take a look at their M3 Series.
Before we go into the actual drive, let’s talk briefly about gaining popularity and generating revenue in the SSD world. There are essentially two ways for an SSD manufacturer to generate revenue. The first is to make a deal with a PC OEM and supply them with SSDs. This is a relatively safe way because OEMs rarely offer more than one or two SSD choices, so if a customer wants an SSD pre-installed, there is a good chance that the drive will be yours. Toshiba’s SSD business model is solely based on OEM sales for example, and having scored a good deal with Apple (they used to be the only supplier of SSDs for Macs, and still ship most of the SSDs used in Macs), they are selling millions of SSDs every year thanks to Apple’s success.
The downside of an OEM partnership is the difficulty of building one. If you look at the SSDs that OEMs offer, they are mostly made by Intel or Samsung. Reliability is far more important for PC OEMs than raw performance figures because when a consumer is buying a computer, he is buying the big picture and not a specific SSD. Nobody likes failures and it should be one of the OEM’s main goals to build a reliable machine to avoid a stained brand image.
Furthermore, Intel and Samsung are both fab owners and use their own proprietary controllers (except for Intel’s Series 520 SATA 6Gb/s SSDs, but the firmware is still custom). Owning a fab means you have total control over what you produce and sell, and also know what to expect in terms of yields. If there is a problem in production, you can focus the available NAND on your own SSD products and ship the leftovers to others. That guarantees a fairly stable supply of SSDs, while fab-less SSD makers are at the mercy of NAND manufacturers and their supply can fluctuate a lot.
Using custom firmware, and especially an in-house controller, removes additional overhead that is produced by a third party controller and firmware. If you go with a drive that uses a third party controller and firmware, when an issue arises you first report it to the manufacturer of the drive, who then reports it to the maker of the controller and/or firmware, and then there's a delay while you wait for the problem to be fixed. SandForce in particularly cannot be praised for the quickness of their firmware updates in the past, and hence it’s a safer bet for PC OEMs to go with a manufacturer who also designs the firmware as it’s easier to work out potential issues that might crop up.
If you can’t establish a relationship with a PC OEM, then you are left with selling SSDs through retailers. This is what most SSD OEMs do and some do it along with OEM sales. The retail market greatly differs from the OEM market. Your SSD is no longer part of the whole product—it is the whole product. That means your SSD has to sell itself. The best way is obviously to have a high performance yet reasonably priced SSD, as that is what buyers will see when buying a product. Reliability is another big concern but it's something you can't really use as a marketing tool because there aren't any extensive, unbiased studies.
The positive side is that if you have an SSD that is very competitive, it will also sell. In the OEM market, you may not get a lot sales if the end-product isn't competitive. Take for example the Razer Blade that we just reviewed. It uses Plextor's M2 SSD (see why I picked the Blade now? Note however that our review sample was an earlier unit that used a Lite-On SSD) but as we mentioned in our review, the Blade is too expensive for what you get. Plextor will of course get some SSD sales through Razer but due to the small niche of the Blade, it's not a gold mine.
As far as brand awareness for Plextor, I believe the reason for their relative obscurity of late has been the lack of media awareness and contacts. Their journey to become an SSD manufacturer has been rather abnormal. When you think of the history of other SSD manufacturers, they were mostly known for RAM before entering the SSD world. Being in the RAM market acts as a shortcut because you are likely to have relations with the media that are interested in your products, plus there is a good chance that people are already familiar with your brand. For optical drive manufacturers, the case is the opposite.
These days, optical drives aren’t tested and benchmarked as much as other components; it’s not a component where people pay a lot attention when building a computer. When most people don’t really care what you are making, it’s tough to create media contacts and build brand image. Coming up with a new product line won’t solve the problem overnight but give it some time and it may. This is essentially what has happened to Plextor—it has taken a few generations of SSDs before consumers and media started recognizing the new player in the game—and now it’s time for us to take a look at what they have been holding in their sleeves.
Facebook
Twitter
RSS
113 Comments
View All Comments
epobirs - Thursday, April 5, 2012 - link
Kind of sad to see a review where Plextor is treated as an unknown. For quite a long time they were the brand against which all others were judged. For one simple reason: ifPlextor said their drive functioned at speed X, it did. If other companies were claiming a new high performance mark and Plextor hadn't produced a matching product yet, it often meant those other companies were lying about their performance.cjcoats - Thursday, April 5, 2012 - link
I'm a scientific user (environmental model), and I have a transaction-pattern I've never seen SSD benchmarks use:My dataset transactions are of the form "read or
write the record for variable V for time T"
(where record-size S may depend upon the variable;
typical values range from 16K to 100 MB).
The datasets have a matching form:
* a header that indexes the variables, their
records, and various other metadata
* a sequence of data records for the time
steps of the variables.
This may be implemented using one of various
standard scientific dataset libraries (netCDF,
HDF, ...)
A transaction basically is of the form:
Seek to the start of the record for variable
V, time T
Read or write S bytes at that location.
NONE of the SSD benchmarks I've seen have this
kind of "seek, then access" pattern. I have the
suspicion that Sandforce based drives will do
miserably with it, but have no hard info.
Any ideas?
bji - Thursday, April 5, 2012 - link
SSDs have no "seek". Your program's concept of "seek" is just setting the blocks that it will be reading to those at the beginning of a file, but from an SSDs perspective, there is little to no difference between the random access patterns used for a particular operation and any other random access patterns. The only significant difference is between random and serial access.My point being, your case sounds like it is covered exactly by the "random write" and "random read" benchmarks. It doesn't matter which part of the file you are "seeking" to, just that your access is non-sequential. All random access is the same (more or less) to an SSD.
This is most of the performance win of SSDs over HDDs - no seek time. SSDs have no head to move and no latency waiting for the desired sectors to arrive under the head.
cjcoats - Friday, April 6, 2012 - link
I guessed you'd understand the obvious: seek() interacts with data-compression.A seek to a 500MB point may depend upon sequentially decompressing the preceding 500 MB of data in order to figure out what the data-compression has done with that 500MB seek-point!
That's how you have to do seeks in conjunction with the software "gzlib", for example.
So how do SandForce drives deal with that scenario ??
Cerb - Saturday, April 7, 2012 - link
Nobody can say exactly the results for your specific uses, but it would probably be best to focus on other aspects of the drives, given performance of the current lot. You might get a 830, while a 520 could be faster at your specific application, but you'd more than likely be dealing with <10% either way. If it was more than that, a good RAID card would be a worthy addition to your hardware.If you must read the file up to point X, then that's a sequential read. If you read an index and then just read what you need, then that's a random read.
Compression of the data *IN*SOFTWARE* is a CPU/RAM issue, not an SSD issue. For that, focus on incompressible data results.
TBH, though, if you must read 500MB into it to edit a single small record, you should consider seekable data formats, instead of wasting all that CPU time.
bji - Saturday, April 7, 2012 - link
They don't use streaming ciphers. They use block ciphers that encrypt each block individually and independently. Once the data makes it to the drive, there is no concept of 'file', it's just 'sectors' or whatever the block concept is at the SATA interface level. As far as the SSD is concerned, no two sectors have any relationship and wear levelling moves them around the drive in seemingly arbitrary (but designed to spread writes out) ways.Basically what happens is that the drive represents the sequence of sectors on the drive using the same linear addressing scheme as is present in hard drives, but maintains a mapping for each sector from the linear address that the operating system uses to identify it, to whatever unrelated actual block and sub-block address on the device that it is physically located at. Via this mapping the SSD controller can write blocks wherever makes the most sense, but present a consistent linear sector addressing scheme to the operating system. The SSD can even move blocks around in the background and during unrelated writes, which it definitely does to reduce write amplification and once again for wear levelling purposes. The operating system always believes that it wrote the sector at address N, and the SSD will always deliver the same data back when address N is read back, but under the covers the actual data can be moved around and positioned arbitrarily by the SSD.
Given the above, and given that blocks are being written all over the flash all the time regardless of how linearly the operating system thinks it has arranged them, there really isn't any concept of contiguously compressed blocks and having to start back at the beginning of some stream of data to uncompress data.
Keep in mind also that the Sanforce drives do de-duplication as well (as far as I know), which means that for many blocks that have the same contents, only one copy needs to actually be stored in the flash and the block mapping can point multiple operating system sector addresses at the same physical flash block and sub-block segment that has the data. Of course it would have to do copy-on-write when the sector is written but that's not hard once you have all of the rest of the controller machinery built.
SSD controllers must be really interesting tech to work on. I can't imagine all of the cool algorithmic tricks that must be going on under the covers, but it's fun to try.
BolleY2K - Thursday, April 5, 2012 - link
Don´t forget about the Yamaha CRW-F1... ;-)Metaluna - Saturday, April 7, 2012 - link
Heh I still have one of those Yamahas, along with some old Kodak Gold CD-R's. I have no real use for them anymore but hate to toss them.Hourglasss - Thursday, April 5, 2012 - link
You made a forgivable mistake with OCZ's Vertex 4. You said the M3 was the fastest non-sandforce drive. The Vertex 4 is made with OCZ's new everest-2 controller that they developed in-house after acquiring indillix (don't know if they spelled that right). So the M3 is fast, but it's second for non sandforce.zipz0p - Thursday, April 5, 2012 - link
I am glad that I'm not the only one who noticed this! :)