We got the first glimpse of Transcend's SSD370 at Computex last year and now the drive has been in retail for quite some time. The interesting bit about the drive is its custom Transcend firmware, which is accompanied by a relabeled Silicon Motion SM2246EN controller (Transcend calls it TS6500). The SM2246EN has increasingly been gaining popularity among SSD vendors, but the SSD370 is the first time I've come across a custom firmware solution. Silicon Motion's business model is similar to SandForce's in the sense that it can deliver the whole package (controller hardware & firmware), but also allows custom firmwares (although I don't know if customers get full source code access, which at least SandForce doesn't allow).

Relabeling the controller is nothing unheard of because at least OCZ and Toshiba have done it in the past. Usually the reason why manufacturers do this is to ensure that their drive isn't mixed with the other drives that use the same controller because even with the same controller the drives can be totally different (excellent case in point is Marvell based SSDs). You would be surprised how often I still see people classifying drives based solely on the controller silicon, so I certainly understand the manufacturers' motivation as it's not exactly fair to judge a drive based on the controller alone. At the end of the day, it's the firmware that designates the drive's performance and reliability - the controller is just a SoC that does the number crunching. I can't say I'm a big fan of controller relabeling because it creates confusion and may be seen as a dubious marketing act, but as long as the manufacturer is open about the real source of the silicon, it's not something that deserves a big call out in my opinion. 

Transcend SSD370 Specifications
Capacity 128GB 256GB 512GB 1TB
Controller Transcend TS6500 (rebranded Silicon Motion SM2246EN)
NAND Micron 128Gbit 20nm MLC
Sequential Read 550MB/s 560MB/s 560MB/s 560MB/s
Sequential Write 170MB/s 320MB/s 460MB/s 460MB/s
4KB Random Read 70K IOPS 70K IOPS 75K IOPS 75K IOPS
4KB Random Write 40K IOPS 70K IOPS 75K IOPS 75K IOPS
Idle Power Consumption 305mW 320mW 325mW 335mW
Read/Write Power Consumption 1.21W / 1.92W 1.28W / 3.11W 1.43W / 3.22W 1.76W / 3.46W
Endurance 150TB 280TB 550TB 1180TB
Warranty Three years
Online Pricing $60 $105 $200 $394

The SSD370 is available in capacities from 32GB to all the way to up to 1TB. I decided to leave out the 32GB and 64GB units from the specification table as I suspect these are mostly OEM-focused models because (to be honest) there isn't a significant retail market for drives smaller than 128GB anymore. In addition to the SSD itself, the retail package includes a 3.5" desktop adapter and for drive migration Transcend provides a cloning function through its own SSD Scope Utility.

By default, the SSD370 doesn't support AES and TCG Opal encryption, but Transcend has a customized firmware that enables encryption. I suspect the custom firmware is aimed towards PC OEMs because the major market for self-encrypting drives (SEDs) is still in business PCs. eDrive, however, is not supported at the moment, although Transcend's plan is to add support in the near future.

The SSD370 doesn't support slumber power modes (HIPM+DIPM) because Transcend decided to disable the feature due to some prior compatibility issues with hosts that didn't properly support the feature. DevSleep, however, is supported according to the data sheet, but there are no power figures to support that, so I'm thinking it's a feature that can potentially be enabled through a custom firmware if a customer requires it.

In the NAND department Transcend uses Micron's 128Gbit 20nm MLC NAND, which is fairly common in more value-oriented drives. Micron has also started shipping its 16nm NAND to customers and I think Mushkin's Reactor was the first SSD to adopt it, but we will likely see many SSD OEMs transitioning to Micron's 16nm during H1'15 as the shipping volumes increase.

Interestingly the SSD370 employs partial power loss protection as there are ceramic capacitors on the PCB to provide power in case of a sudden power loss. Ceramic capacitors are fairly low capacity and can't provide the necessary power to flush everything from the DRAM cache to NAND, so user data in the DRAM is still in jeopardy, but the capacitors ensure that data at rest (i.e. in lower pages) and the NAND mapping table are safe. That's similar to what Micron did with the M600 and I suggest you read the review if you are looking for a more in-depth explanation regarding client-level power loss protection.

Another intriguing feature is what Transcend calls StaticDataRefresh Technology. As the 840 EVO performance degradation bug taught us, the charge in cells degrades over time, which results in errors when the cell is read. ECC can fix a certain number of error bits, but if the limit is exceeded corrupted data will be sent to the host. The StaticDataRefresh technology monitors the error rates and when a preset threshold value is reached, the data will be rewritten to restore the correct cell charge level. I suspect all SSDs do this because it's vital to ensure the health of old data, but it's the first time I've seen it mentioned in a data sheet.

Test Systems

For AnandTech Storage Benches, performance consistency, random and sequential performance, performance vs. transfer size, and load power consumption we use the following system:

CPU Intel Core i5-2500K running at 3.3GHz (Turbo & EIST enabled)
Motherboard ASRock Z68 Pro3
Chipset Intel Z68
Chipset Drivers Intel + Intel RST 10.2
Memory G.Skill RipjawsX DDR3-1600 4 x 8GB (9-9-9-24)
Video Card Palit GeForce GTX 770 JetStream 2GB GDDR5 (1150MHz core clock; 3505MHz GDDR5 effective)
Video Drivers NVIDIA GeForce 332.21 WHQL
Desktop Resolution 1920 x 1080
OS Windows 7 x64

Thanks to G.Skill for the RipjawsX 32GB DDR3 DRAM kit

For slumber power testing we used a different system:

CPU Intel Core i7-4770K running at 3.3GHz (Turbo & EIST enabled, C-states disabled)
Motherboard ASUS Z87 Deluxe (BIOS 1707)
Chipset Intel Z87
Chipset Drivers Intel + Intel RST 12.9
Memory Corsair Vengeance DDR3-1866 2x8GB (9-10-9-27 2T)
Graphics Intel HD Graphics 4600
Graphics Drivers
Desktop Resolution 1920 x 1080
OS Windows 7 x64
Performance Consistency & TRIM Validation
Comments Locked


View All Comments

  • Hulk - Tuesday, January 27, 2015 - link

    Perhaps I missed it but no mention/testing of endurance? All I see are manufacturer quoted numbers in the table.
  • DanNeely - Tuesday, January 27, 2015 - link

    Barring catastrophic failures, endurance testing a drive to destruction takes many months. Tech Report started torturing a set of 256GB drives in late 2013; as of last month 2 of the 6 drives were still running.

  • Hulk - Tuesday, January 27, 2015 - link

    I guess you don't read Anandtech much. Generally they run down the drive enough to move the counter down a few percent, then make a good estimate of endurance based on those numbers. I think it's very interesting and pretty much only Anandtech does it. Or used to do it.
  • extide - Tuesday, January 27, 2015 - link

    Maybe it's you that doesn't read AT that much ;) (Haha, I had to)

    They typically will only do that when they are testing drives with a new type of NAND that we haven't seen yet before, or testing some weird scenario, or something like that. Micron 20nm NAND is a well known entity at this point, and even though they are using custom firmware on this controller, it's performance and behavior seems very similar to the stock SMI firmware -- so basically there is nothing remarkable here. I am sure the endurance will be similar to most other drives with this type of NAND.
  • Kristian Vättö - Tuesday, January 27, 2015 - link

    Right on the spot. I only do endurance testing with new NAND generations that we haven't seen before to figure out the P/E cycle rating. It takes days, possibly weeks, so there is no point in testing that with every drive. After all, the manufacturers' ratings still matter because once those are reached the warranty will be voided anyway, so my endurance tests aim to tell more about the NAND than the drive itself.
  • Hulk - Tuesday, January 27, 2015 - link

    Okay makes sense.
    I can admit when I'm wrong.
  • Hulk - Tuesday, January 27, 2015 - link

    But wait. Does it take days or weeks to run down the counter 1 or 2 percent? That's all you need to get an estimate on actual endurance right?
    And isn't there variation in the NAND that each manufacturer buys for each line of drives? I'm talking about the binning and how endurance can vary for the same process.
  • Kristian Vättö - Tuesday, January 27, 2015 - link

    The problem is finding the exact spot where the counter changes by 1 percent, so it usually takes at least a few percent worth of cycling to find that. Generally it takes a couple of days for client drives, but even then that time is away from testing other drives.

    You are correct that not every die is equal, but the P/E cycle rating is usually conservative to guarantee that all SSD-grade dies comply that spec. With binning and parameter trimming it's possible to get much more out of the dies though.
  • Hulk - Tuesday, January 27, 2015 - link

    Wow. Thanks for the specific reply.
  • Souka - Wednesday, January 28, 2015 - link

    Just thought to share:

    I've fried 3 brand new SSDs in my torrent box over the past year. Granted two were 64GB, one 120GB, and they were pretty meh to begin with performance wise.

    I knew the SSD wouldn't last, but didn't expect it to fail that quickly. Currently have an OLD 64GB Intel SLC (X25 I think) in for past few months...no issue yet.

Log in

Don't have an account? Sign up now