Adata’s Ultimate SU800 512GB SSD reviewed

Not so long ago, we took an in-depth look at Micron’s first foray into the 3D NAND world. While Micron took much longer to bring its 3D floating-gate cells to market than Samsung did with its charge-trap based V-NAND, the MX300 proved to be worth the wait.

But there are more differences between Micron and Samsung than merely the nature of their cell-stacking technologies. Samsung doesn’t sell its NAND flash to smaller, fab-less SSD brands to bin and repackage. Instead, Samsung goes it alone with vertically-integrated products marketed to OEMs, system integrators, and consumers alike. Micron, on the other hand, is more than happy to sell the little guys some of its bits and pieces. So while Samsung’s V-NAND may have drawn first blood, Micron’s 3D NAND debut heralds the coming of a whole ecosystem of products with 3D flash inside.

Adata is as frequent an integrator of Micron NAND as any fab-less manufacturer, and it quickly snagged some of Micron’s 3D NAND to develop a brand-new SSD in these early days of the new 3D NAND market. To be clear, Adata’s product description and marketing materials don’t make any mention of Micron. But since the company specifically referenced floating-gate cells in earlier press releases about the drive, there was never much doubt about whose NAND was inside. After all, the competing products from Toshiba and Hynix are both based on charge-trap flash. Anyway, Adata’s Ultimate SU800 looks to offer a similar package as Crucial’s MX300—a compelling blend of 3D TLC performance and a price that won’t break the bank. Take a look at the basic specs.

Adata SU800
Capacity Max sequential (MB/s) Max random (IOps)
Read Write Read Write
128GB 560 300 50k 75k
256GB 560 520 80k 85k
512GB 560 520 85k 85k
1TB 560 520 80k 80k

We wasted little time in pulling apart the 512GB sample Adata sent us. As suspected, Micron’s TLC 3D NAND is what’s inside. Instead of the eight-package configuration we saw inside the MX300 750GB, though, this time around there are only six packages for a total of 576GB. Gotta have a little extra for overprovisioning, after all.

Two of the six packages share a side of the PCB with the drive’s controller and DRAM cache. Silicon Motion’s SM2258, the company’s latest low-cost controller, runs the show. That chip is specifically designed for 3D TLC applications. The SM2258 seems to be a natural evolution of the company’s preceding 2246 and 2256 controllers, featuring pseudo-SLC caching, Silicon Motion’s proprietary “NANDXtend” ECC scheme, and the full caboodle of encryption features.

Unfortunately, the SU800 doesn’t seem to make use of those encryption features, so look elsewhere if you like to keep your data secret and safe. On the bright side, Adata warrants the drive for three years. Additionally, the company touts the drive’s endurance over planar TLC offerings. Indeed, the 512GB unit’s 400 terabytes-written spec greatly eclipses the SP550 480GB’s 180TB-written rating.

The SU800 is already widely available, and the 512GB version we’re testing today can be had for $129.99 at Newegg. A quarter per gig isn’t the lowest price we’ve ever seen for a 512GB SSD, but it’s still reasonable provided the SU800’s performance is up to snuff. Let’s see whether that’s the case now.


IOMeter — Sequential and random performance

IOMeter fuels much of our latest storage test suite, including our sequential and random I/O tests. These tests are run across the full capacity of the drive at two queue depths. The QD1 tests simulate a single thread, while the QD4 results emulate a more demanding desktop workload. For perspective, 87% of the requests in our old DriveBench 2.0 trace of real-world desktop activity have a queue depth of four or less. Clicking the buttons below the graphs switches between results charted at the different queue depths.

Our sequential tests use a relatively large 128KB block size.

The SU800’s sequential read speeds are superb, matching the fastest SATA SSDs and offering a modest increase over the MX300’s reads. Its write numbers trail even the notoriously pokey Crucial BX200, however. We brought up our numbers with Adata before publication, and the company replicated our test setup and confirmed that our results are no anomaly. The official explanation is that the drive’s SLC-cache has not recovered in between IOMeter filling the drive with its test file and actually executing our scripted benchmarks. We’ve seen similar problems with other drives before, but none have yielded such a troublesome end result.

The 28 MB/s figure we’re seeing is essentially the TLC NAND’s true write speed when caching tricks aren’t in play. It’s not entirely clear why some drives are able to flush their caches enough to be able to operate at acceptable speeds while others have such a terrible time of it, but we can hazard some guesses. One of the features of the SM2258 is a “direct-to-TLC algorithm,” which enables the controller to bypass the SLC buffer when it’s saturated and shuttle incoming writes directly to the drive’s TLC. It’s possible that our IOMeter setup has exposed an unusual behavior in the controller’s programming regarding when to use or skip the SLC cache mode.

Without another SM2258 drive on hand to compare against, it’s hard to know whether to point the finger at Adata or Silicon Motion here. But results are results, so the SU800 will have to work hard to make up for that 28 MB/s black mark throughout the rest of our testing suite.

For better or for worse, the drive’s random response times aren’t particularly exciting. Read responses are a bit quicker than the MX300’s were, but write responses are substantially slower. Let’s move on to some more interesting tests.


Sustained and scaling I/O rates

Our sustained IOMeter test hammers drives with 4KB random writes for 30 minutes straight. It uses a queue depth of 32, a setting that should result in higher speeds that saturate each drive’s overprovisioned area more quickly. This lengthy—and heavy—workload isn’t indicative of typical PC use, but it provides a sense of how the drives react when they’re pushed to the brink.

We’re reporting IOps rather than response times for these tests. Click the buttons below the graph to switch between SSDs.

The SU800’s sustained random performance echoes the results we saw in our sequential write tests. We expect to see drives hit a high peak early on in this test, then eventually settle down to a much lower steady-state speed as their caching schemes and overprovisioning are overwhelmed. In the SU800’s case, its cache has given up the ghost already by the time the test begins. All we have here is 30 minutes of relatively slow writes.

But that’s not to say that the actual steady-state speed is necessarily bad. To show the data in a slightly different light, we’ve graphed the peak random-write rate and the average, steady-state speed over the last minute of the test.

The SU800’s steady-state TLC write rate is actually quite good, narrowly beating the 850 EVO’s TLC V-NAND and even the planar MLC in the MX200. And it’s almost double that of the MX300. Not bad at all, in context.

Our final IOMeter test examines performance scaling across a broad range of queue depths. We ramp all the way up to a queue depth of 128. Don’t expect AHCI-based drives to scale past 32, though—that’s the maximum depth of their native command queues.

For this test, we use a database access pattern comprising 66% reads and 33% writes, all of which are random. The test runs after 30 minutes of continuous random writes that put the drives in a simulated used state. Click the buttons below the graph to switch between the different drives. And note that the P3700 plot uses a much larger scale.

The SU800’s humdrum scaling won’t get anybody’s heart pounding, but it’s no more humdrum than any run-of-the-mill SATA drive. In fact, you may notice that the scaling curves are quite similar to Adata’s SP550. Let’s plot ’em against each other to try and spot the differences.

The JMicron controller in the XPG SX930 afforded it little scaling performance. The Marvell chip in the MX300 scaled almost linearly as queue depth increased. The Silicon Motion-equipped SP550 and SU800 have a bit more ebb and flow to their curves than the MX300 did, but the end results don’t look all that different from the MX300’s.

The SU800 can now breathe a sigh of relief, since we’re putting IOMeter aside to explore some real-world testing with RoboBench.


TR RoboBench — Real-world transfers

RoboBench trades synthetic tests with random data for real-world transfers with a range of file types. Developed by our in-house coder, Bruno “morphine” Ferreira, this benchmark relies on the multi-threaded robocopy command build into Windows. We copy files to and from a wicked-fast RAM disk to measure read and write performance. We also cut the RAM disk out of the loop for a copy test that transfers the files to a different location on the SSD.

Robocopy uses eight threads by default, and we’ve also run it with a single thread. Our results are split between two file sets, whose vital statistics are detailed below. The compressibility percentage is based on the size of the file set after it’s been crunched by 7-Zip.

  Number of files Average file size Total size Compressibility
Media 459 21.4MB 9.58GB 0.8%
Work 84,652 48.0KB 3.87GB 59%

The media set is made up of large movie files, high-bitrate MP3s, and 18-megapixel RAW and JPG images. There are only a few hundred files in total, and the data set isn’t amenable to compression. The work set comprises loads of TR files, including documents, spreadsheets, and web-optimized images. It also includes a stack of programming-related files associated with our old Mozilla compiling test and the Visual Studio test on the next page. The average file size is measured in kilobytes rather than megabytes, and the files are mostly compressible.

RoboBench’s write and copy tests run after the drives have been put into a simulated used state with 30 minutes of 4KB random writes. The pre-conditioning process is scripted, as is the rest of the test, ensuring that drives have the same amount of time to recover.

Let’s take a look at the media set first. The buttons switch between read, write, and copy results.

The SU800 again offers exemplary read speeds for a SATA drive. And its writes are perfectly fine in this real-world test of performance. The warts we uncovered with IOMeter are smoothed over with a layer of SLC-cache-makeup that’s good enough to fool RoboBench. The SU800 writes as fast as the MX300 when tasked with basic file operations. Despite starting out on the wrong foot, there’s hope for this drive yet.

The SU800 handles the work set just fine, too. With either one or eight threads, the drive puts up numbers right in line with the MX300’s across our read, write, and copy tests.

RoboBench has partially redeemed the SU800, but there’s one last hurdle left to clear. On the next page, we load the drive up with Windows and various applications to see how it performs as primary storage.


Boot times

Until now, all of our tests have been conducted with the SSDs connected as secondary storage. This next batch uses them as system drives.

We’ll start with boot times measured two ways. The bare test depicts the time between hitting the power button and reaching the Windows desktop, while the loaded test adds the time needed to load four applications—Avidemux, LibreOffice, GIMP, and Visual Studio Express—automatically from the startup folder. Our old boot tests focused on the time required to load the OS, but these new ones cover the entire process, including drive initialization.

The SU800 boots up with typical SSD briskness. We would have been shocked if it didn’t.

Load times

Next, we’ll tackle load times with two sets of tests. The first group focuses on the time required to load larger files in a collection of desktop applications. We open a 790MB 4K video in Avidemux, a 30MB spreadsheet in LibreOffice, and a 523MB image file in the GIMP. In the Visual Studio Express test, we open a 159MB project containing source code for the LLVM toolchain. Thanks to Rui Figueira for providing the project code.

Productivity applications pose no problem for the SU800. Our last task is to see how quickly it loads games.

The drive falls in the middle of the pack across all three games. That’s plenty good enough for it to serve as a game library drive should an owner task it with that duty.

That’s it for our tests. Our IOMeter-induced misgivings have been somewhat assuaged by the real-world results this drive puts up. The next page details our test setup, but we won’t be too upset if you skip ahead to the conclusion.


Test notes and methods

Here are the essential details for all the drives we tested:

  Interface Flash controller NAND
Adata Premier SP550 480GB SATA 6Gbps Silicon Motion SM2256 16-nm SK Hynix TLC
Adata Ultimate SU800 512GB SATA 6Gbps Silicon Motion SM2258 32-layer Micron 3D TLC
Adata XPG SX930 240GB SATA 6Gbps JMicron JMF670H 16-nm Micron MLC
Crucial BX100 500GB SATA 6Gbps Silicon Motion SM2246EN 16-nm Micron MLC
Crucial BX200 480GB SATA 6Gbps Silicon Motion SM2256 16-nm Micron TLC
Crucial MX200 500GB SATA 6Gbps Marvell 88SS9189 16-nm Micron MLC
Crucial MX300 750GB SATA 6Gbps Marvell 88SS1074 32-layer Micron 3D TLC
Intel X25-M G2 160GB SATA 3Gbps Intel PC29AS21BA0 34-nm Intel MLC
Intel 335 Series 240GB SATA 6Gbps SandForce SF-2281 20-nm Intel MLC
Intel 730 Series 480GB SATA 6Gbps Intel PC29AS21CA0 20-nm Intel MLC
Intel 750 Series 1.2TB PCIe Gen3 x4 Intel CH29AE41AB0 20-nm Intel MLC
Intel DC P3700 800GB PCIe Gen3 x4 Intel CH29AE41AB0 20-nm Intel MLC
Mushkin Reactor 1TB SATA 6Gbps Silicon Motion SM2246EN 16-nm Micron MLC
OCZ Arc 100 240GB SATA 6Gbps Indilinx Barefoot 3 M10 A19-nm Toshiba MLC
OCZ Trion 100 480GB SATA 6Gbps Toshiba TC58 A19-nm Toshiba TLC
OCZ Trion 150 480GB SATA 6Gbps Toshiba TC58 15-nm Toshiba TLC
OCZ Vector 180 240GB SATA 6Gbps Indilinx Barefoot 3 M10 A19-nm Toshiba MLC
OCZ Vector 180 960GB SATA 6Gbps Indilinx Barefoot 3 M10 A19-nm Toshiba MLC
Plextor M6e 256GB PCIe Gen2 x2 Marvell 88SS9183 19-nm Toshiba MLC
Samsung 850 EV0 250GB SATA 6Gbps Samsung MGX 32-layer Samsung TLC
Samsung 850 EV0 1TB SATA 6Gbps Samsung MEX 32-layer Samsung TLC
Samsung 850 Pro 500GB SATA 6Gbps Samsung MEX 32-layer Samsung MLC
Samsung 950 Pro 512GB PCIe Gen3 x4 Samsung UBX 32-layer Samsung MLC
Samsung 960 Pro 2TB PCIe Gen3 x4 Samsung Polaris 48-layer Samsung MLC
Samsung SM951 512GB PCIe Gen3 x4 Samsung S4LN058A01X01 16-nm Samsung MLC
Samsung XP941 256GB PCIe Gen2 x4 Samsung S4LN053X01 19-nm Samsung MLC
Toshiba OCZ RD400 512GB PCIe Gen3 x4 Toshiba TC58 15-nm Toshiba MLC
Toshiba OCZ VX500 512GB SATA 6Gbps Toshiba TC358790XBG 15-nm Toshiba MLC
Transcend SSD370 256GB SATA 6Gbps Transcend TS6500 Micron or SanDisk MLC
Transcend SSD370 1TB SATA 6Gbps Transcend TS6500 Micron or SanDisk MLC

All the SATA SSDs were connected to the motherboard’s Z97 chipset. The M6e was connected to the Z97 via the motherboard’s M.2 slot, which is how we’d expect most folks to run that drive. Since the XP941, 950 Pro, RD400, and 960 Pro require more lanes, they were connected to the CPU via a PCIe adapter card. The 750 Series and DC P3700 were hooked up to the CPU via the same full-sized PCIe slot.

We used the following system for testing:

Processor Intel Core i5-4690K 3.5GHz
Motherboard Asus Z97-Pro
Firmware 2601
Platform hub Intel Z97
Platform drivers Chipset:


Memory size 16GB (2 DIMMs)
Memory type Adata XPG V3 DDR3 at 1600 MT/s
Memory timings 11-11-11-28-1T
Audio Realtek ALC1150 with drivers
System drive Corsair Force LS 240GB with S8FM07.9 firmware
Storage Crucial BX100 500GB with MU01 firmware

Crucial BX200 480GB with MU01.4 firmware

Crucial MX200 500GB with MU01 firmware

Intel 335 Series 240GB with 335u firmware

Intel 730 Series 480GB with L2010400 firmware

Intel 750 Series 1.2GB with 8EV10171 firmware

Intel DC P3700 800GB with 8DV10043 firmware

Intel X25-M G2 160GB with 8820 firmware

Plextor M6e 256GB with 1.04 firmware

OCZ Trion 100 480GB with 11.2 firmware

OCZ Trion 150 480GB with 12.2 firmware

OCZ Vector 180 240GB with 1.0 firmware

OCZ Vector 180 960GB with 1.0 firmware

Samsung 850 EVO 250GB with EMT01B6Q firmware

Samsung 850 EVO 1TB with EMT01B6Q firmware

Samsung 850 Pro 500GB with EMXM01B6Q firmware

Samsung 950 Pro 512GB with 1B0QBXX7 firmware

Samsung XP941 256GB with UXM6501Q firmware

Transcend SSD370 256GB with O0918B firmware

Transcend SSD370 1TB with O0919A firmware

Power supply Corsair AX650 650W
Case Fractal Design Define R5
Operating system Windows 8.1 Pro x64

Thanks to Asus for providing the systems’ motherboards, to Intel for the CPUs, to Adata for the memory, to Fractal Design for the cases, and to Corsair for the system drives and PSUs. And thanks to the drive makers for supplying the rest of the SSDs.

We used the following versions of our test applications:

Some further notes on our test methods:

  • To ensure consistent and repeatable results, the SSDs were secure-erased before every component of our test suite. For the IOMeter database, RoboBench write, and RoboBench copy tests, the drives were put in a simulated used state that better exposes long-term performance characteristics. Those tests are all scripted, ensuring an even playing field that gives the drives the same amount of time to recover from the initial used state.

  • We run virtually all our tests three times and report the median of the results. Our sustained IOMeter test is run a second time to verify the results of the first test and additional times only if necessary. The sustained test runs for 30 minutes continuously, so it already samples performance over a long period.

  • Steps have been taken to ensure the CPU’s power-saving features don’t taint any of our results. All of the CPU’s low-power states have been disabled, effectively pegging the frequency at 3.5GHz. Transitioning between power states can affect the performance of storage benchmarks, especially when dealing with short burst transfers.

The test systems’ Windows desktop was set at 1920×1080 at 60Hz. Most of the tests and methods we employed are publicly available and reproducible. If you have questions about our methods, hit our forums to talk with us about them.



Adata’s SU800 got off to a rocky start with our IOMeter sequential write test, but its real-world performance should have at least partially made up for that. Let’s see where it lands overall. To compare each drive, we take the geometric mean of a basket of results from our test suite. Only drives that have been through the entire current test suite on our current rig are represented.

In our final reckoning, the SU800’s performance in our IOMeter sequential test remains a burden, even with its solid real-world performance numbers. To be fair, our overall performance chart can hide bright spots in a drive’s showing, and the SU800 is certainly a faster drive in real-world scenarios than Adata’s own SP550 and even the Crucial MX300. Even so, its performance in some of our synthetic tests makes us wary.

At the very least, the SU800 should make for a relatively cheap and swift system drive, and it could also serve well as a home for a Steam library, provided the price is palatable. Our scatter plots will give us the context to make that determination. Use the buttons to switch between views of all drives, only SATA drives, or only PCIe drives. The most compelling position in these scatter plots is toward the upper left corner, where the price per gigabyte is low and performance is high.

The SU800 512GB isn’t too dear at $0.25 per gigabyte, but Adata’s own planar TLC drive—the SP550 480GB—costs the same while offering a bit more overall performance. It’s also worth considering that Crucial’s MX300 525GB drive goes for about the same price, and the 750GB version of that SSD made it through our tests without any bumps or bruises.

If Adata (or possibly Silicon Motion) sorts out the demonstrated issues the SU800 has with write-cache flushing, this drive will climb in our rankings and become a genuinely compelling SSD. We’ll keep you posted if that situation changes. For the time being, however, builders will need to weigh the SU800’s speedy real-world performance and affordable price tag against a potentially troublesome performance corner case lurking in the shadows.

Comments closed
    • Waco
    • 6 years ago

    None of these would stress this drive. I’ll give you unzipping archives, but if you’re unzipping something that huge, why do it on an SSD at all?

    • derFunkenstein
    • 6 years ago

    Two of those are not gated by even the slowest SSD. Installing Windows from a thumb drive? Where most of those are even today still quite slow for reading? Downloading a large file? Even 30MB/sec is 240mbit, which almost nobody has for an internet connection.

    I’ll give you unzipping archives, but I do that pretty infrequently myself. And I’ll still take the slowest SSD over a 5400RPM hard drive because 99% of what I use it for is not unzipping archives.

    • weaktoss
    • 6 years ago

    Stopwatch, median of 3 trials for each test. It certainly is tedious, but those are the kind of sacrifices we make for our readers 🙂

    There are definitely lower-effort ways to log boot time, but we like to use a stopwatch to cover the whole process (from power on to desktop showing up).

    • Rza79
    • 6 years ago

    IOMeter giving issues with SLC-caching… not the first time.
    Some firmwares just don’t play right with an unpartitioned drive.

    • 6 years ago

    Hey Tony,
    Couple of requests-Could you please give us the buffer size of the SLC cach on drives.
    Also the 4K-QD1 Read.In the future…………………..

    Checking elsewhere the buffer on this drive seems to be around 60GB.
    And the 4K read is close to 9K iops,so it should be quite snappy as a boot drive.

    Don’t deserve to be down there with the BX200 and Trion 100 (borderline lemons)
    on that chart.

    • Takeshi7
    • 6 years ago

    streaming writes are still quite common during normal usage for a consumer system. Downloading large files. Unzipping archives. Installing Windows. etc.

    • Chrispy_
    • 6 years ago

    There are plenty of applications that monitor boot time, most of these just read the boot logs so if Tony’s not using an application he’s probably just reading the log timestamps.

    • Waco
    • 6 years ago

    2016: The year people stop caring about sustained write speeds on drives that don’t see streaming writes?

    In every way this is a good balance for a consumer system. Fast enough writes, extremely good reads.

    • Takeshi7
    • 6 years ago

    2016: The year a 5400 RPM HDD can handle 5x higher sequential write speed than an SSD.

Pin It on Pinterest

Share This

Share this post with your friends!