Write Cache Testing

For hybrid SSDs like this, sometimes you just need to roll up your sleeves and do some poking around outside of the typical benches. With the Samsung EVO series drives, I was able to verify cache by simply watching an HDTune write pass with a stopwatch in hand. First I tried this with the Trion 100's:

ocz-trion-960-10.png

Well that clearly wasn't going to work here. Either the cache is too small to measure or the Trion just does not like this particular write workload and immediately falls back into TLC mode.

Let's try something simpler. Here I'll just copy some files to it. Can't be that bad, right? First a couple of Samsung 850 EVOs for reference of what behavior we expect to see in a hybrid situation. I'm copying 5 4GB files over in this test, which translates to 2GB per division. A slight dip after each file (2 divisions) is just a Windows file copy thing:

fc-850evo120.png

The 850 EVO 120GB writes 5GB at SLC speeds before dropping to its TLC speed of 148 MB/sec (rated 150 MB/sec).

fc-850evo500.png

The 850 EVO 500GB never seems to get into its TLC area, but in reality Samsung's VNAND is sufficiently fast that the TLC speed at this capacity is enough to keep things going full speed regardless.

Now onto the OCZ Trion 100:

fc-trion240.png

The 240GB Trion 100 ran out of cache at just over 2GB written, with its sustained write speed coming in at 113 MB/sec. Not bad for a low capacity unit on planar TLC flash. We would normally expect these figures to increase as we raise capacity. Let's see what happens:

fc-trion480.png

With double the number of flash dies, the 480GB Trion 100 runs out of cache *sooner* than the 240GB model and its sustained speed is only up by 7 MB/sec over the model of half the capacity. We would have expected to see a 100% improvement here, not 6%.

fc-trion960.png

The 960GB Trion 100 makes it to just past 4GB of caching and then promptly drops to 125 MB/sec.

We can only assume that these poor sustained write speeds are the result of something in the SSD controller itself, since the 960GB model has quadruple the available dies to write to, yet only sees a 10% improvement in throughput (should be 400%). Our only possible working theory is Toshiba's software implementation of QSB Code in firmware. If they are in fact using the Phison S10 controller as a base, it is doubtful that silicon was optimized for Toshiba's proprietary error correction technology, and as a result we are seeing a controller just doing the QSB math as fast as it can – in software.

« PreviousNext »