For full details of how we conduct our Iometer tests, please refer to this article.
Most modern SATA drives have more or less the same sequential read performance and the 2TB Pro and EVO are no exceptions. Samsung drives do consume quite a bit of power under sequential read operations, but fortunately the 2TB EVO shows efficiency gains over the 1TB model.
Nothing special in the scaling graphs -- both the Pro and EVO reach their maximum at QD2.
Sequential Write Performance
Once again, the performance of 2TB models is equal to 1TB with the EVO having increased power efficiency.
Queue depth scaling is, unsurprisingly, similar to the smaller capacities.
the bug is related to the incorrect Qued trim support on the Samsung drives
the 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)
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)
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)
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.
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.
We’ve updated our terms. By continuing to use the site and/or by logging into your account, you agree to the Site’s updated Terms of Use and Privacy Policy.
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.