The 2TB Samsung 850 Pro & EVO SSD Review
by Kristian Vättö on July 23, 2015 10:00 AM ESTMixed Random Read/Write Performance
For full details of how we conduct our Iometer tests, please refer to this article.
In mixed 4KB random performance the 2TB Pro shows rather significant gains over the 512GB model. I was always surprised how poorly the 850 Pro performed in this test, so it's good to see Samsung paying attention to this, especially since the performance increase comes with dramatically improved power efficiency.
 |
|||||||||
The 512GB Pro had performance and power issues once over half of the IOs were writes, but the 2TB model shows quite optimal performance scaling.
Mixed Sequential Read/Write Performance
In mixed sequential workload performance of both the 2TB Pro and EVO is further improved with the Pro topping the chart. The 2TB EVO is again more power efficient than the 1TB model, whereas the 2TB Pro consumes only a little more power than the 512GB model (this was expected because large sequential IOs utilize multiple dies and with 2TB having more NAND there are more dies drawing power).
The improvement has been in the critical 60/40 and 40/60 distributions. Quite a few drives have an infamous "bathtub" curve where performance severely degrades, but the 2TB Pro and EVO are fairly consistent though all distributions. It's great to see Samsung improving mixed performance because typically it has been an area that has been forgotten in client SSDs, but under real world workloads IOs tend consist of both reads and writes.
 |
|||||||||
Facebook
Twitter
RSS
66 Comments
View All Comments
leexgx - Thursday, July 23, 2015 - link
the bug is related to the incorrect Qued trim support on the Samsung drivesthe samsung drives says they support Qued Trim support but they failed to implement it correctly when they added SATA 3.2 in the latest firmware updates, the Old firmware did not have Qued trim bug because the SSD did not advertise support for it, other SSDs that advertise Qued support it have been patched or don't have the buggy support to start off with (accept the m500)
editorsorgtfo - Thursday, July 23, 2015 - link
Can you corroborate this? Nothing in the patch hints at a vendor issue.leexgx - Thursday, July 23, 2015 - link
i guess this is relating to RAID , there is a failed implementation of advertised Queued Trim support in the samsung 840 and 850 evo/pro drives (the drive says it supports it but it does not support it correctly so TRIM commands are issued incorrectly as to why there is a black list for all 840* and 850* drives)your post seems to be related to RAID and kernel issue (but the issue did not happen on Intel drives that they changed to) they rebuilt there intel SSD setups the same as the samsung ones
they did the same auto restore only the drives changed they had 0 problems once they changed to intel/"other whatever it was" SSDs that also supported Qued TRIM even thought they was not using it the RAID bit probably was (was a bit ago when i looked at it)
sustainednotburst - Friday, July 24, 2015 - link
Algolia stated Queued Trim is disabled on their systems, so its not related to Queued Trim.leexgx - Saturday, July 25, 2015 - link
the problem with samsung drives and Qued trim is till there (not just fake qued trim they failed to implement they also failed to implement the 3.2 spec and the advertised features that samsung is exposing)Gigaplex - Thursday, July 23, 2015 - link
Those two links show separate bugs. The algolia reported bug was a kernel issue. The second bug which vFunct was probably referring to is a firmware bug where the SSD advertises queued TRIM support but does not handle it correctly. The kernel works around this by blacklisting queued TRIM from known-bad drives. Windows doesn't support queued TRIM at all which is why you don't see the issue there yet.jann5s - Thursday, July 23, 2015 - link
@AT: please do some data retention measurements with SSD drives! I'm so curious to see if the myth is true and to what extent!Shadowmaster625 - Thursday, July 23, 2015 - link
With 2 whole gigabytes of DRAM, why are random writes not saturating the SATA bus?Kristian Vättö - Thursday, July 23, 2015 - link
The extra DRAM is needed for the NAND mapping table, it's not used to cache any more host IOs.KaarlisK - Thursday, July 23, 2015 - link
Where did TRIM validation go? (The initial approach, which checked whether TRIM restored performance on a filled drive).Considering that controllers have had problems with TRIM not restoring performance, even if this is a minor revision, it still seems an important aspect to test.