性能曲线测试考量的是顺序读写的情况,而在真实使用过程中,用户更多遇到的情况是随机访问。
我们使用ULINK
DriveMaster 2015 SATA的脏盘测试,看看随着写入量的增加,SSD的随机写入性能会有什么样的变化。
测试对象依然是以下四位,均为120/128G容量
型号 |
主控 |
闪存颗粒 |
固件 |
联想 SL1700 闪电鲨 |
SMI 2258XT |
TLC |
SMI Turnkey |
金士顿 A400 |
Phison S11 |
Kingston |
Phison Turnkey |
闪迪 加强版 |
SMI 2258XT |
SanDisk TLC |
SMI Turnkey |
建兴V5 |
SMI 2254 |
TLC |
LiteOn自行开发 |
DM的脏盘测试步骤如下:
- 先对全盘做两次顺序写入 – 这么做的目的是保证所有待测盘的状态一致(SSD Performance Test Spec也是这么规定的)
- 整盘擦除
- 使用4K Block Size对SSD做持续随机写入
- 一直写直到写入量=2倍容量
- 期间每分钟统计一次IOPS (平均值)
您觉得一块120G的SSD,用4K随机写的方式写入自身容量2倍的数据,大概需要多久?
测试结果让我们有点意外,我们测试的四块120G SATA SSD,其中3块都差不多花了整整1天时间,才完成了2次随机写全盘覆盖…
先看图
具体数据:
DriveMaster 脏碟性能测试 |
||||||||||||
|
0% |
10% |
20% |
30% |
40% |
50% |
75% |
100% |
125% |
150% |
175% |
200% |
Kingston A400 |
1679 |
1331 |
973 |
914 |
777 |
606 |
539 |
556 |
483 |
498 |
476 |
407 |
Lenovo SL700 闪电鲨 |
2573 |
1871 |
1598 |
1140 |
1017 |
997 |
789 |
748 |
592 |
601 |
505 |
499 |
建兴 V5 |
11840 |
11840 |
11542 |
10651 |
10341 |
10059 |
5299 |
3558 |
2519 |
1940 |
1497 |
1210 |
SanDisk 加强版 |
2507 |
1261 |
1590 |
1607 |
1580 |
1599 |
855 |
584 |
514 |
383 |
345 |
256 |
建兴V5的表现独树一帜,有点碾压其他几位的意思。
建兴V5,联想SL1700和闪迪加强版采用的都是SMI的主控,而金士顿A400采用的Phison的主控。
需要注意的是,2254主控是SMI为建兴特别定制的,同时固件为LiteOn自己开发,其他三款都是使用的主控厂商提供的Turnkey FW。
但是仅仅一个固件的不同,不可能造成这么大的性能差距–这么大的锅,固件工程师绝对不能背。
更意外的是,我们用Anvril’s Storage对想SL1700和建兴V5两块盘进行了4K随机写性能的测试,联想SL1700居然比建兴V5还好。
联想SL1700
建兴V5
是什么原因导致了这样的差异?
第一个原因:联想SL1700和闪迪加强版使用的SMI2258XT是Dramless主控…,金士顿A400使用的Phison S11也是Dramless,而建兴使用的SMI 2254,是带DDR的…
在工作过程中,建兴V5的映射表可以全部存在DDR里,其他三块盘只能存当前使用的一小块映射表到SDRAM,其余部分则需要存在NAND上,然后频繁换取。
通常Benchmark的随机写入测试,都是在一个指定范围内的随机,比如1G空间,而DriveMaster的脚本是”全盘”随机写操作。
固件需要反复的从Flash里读出不同部分的Mapping table,然后修改,再写回Flash,再读取下一段Mapping table…
因此对于Dramless的SSD来说,一个简单的4K写入,实际上可能是4K的数据写入+4K的mapping table读取+4K的mapping table写入,画面简直太美。
Ulink方面协助我们进行了分析,通过DriveMaster 2015自带的IO Trace,我们对比了建兴V5和联想SL1700的平均时延:
建兴V5是1,191us, 联想SL1700是17,387us.
第二个原因:DriveMaster的脏盘测试,IO采用的是非4K对齐,而Benchmark工具,基本采用的都是4K对齐的方式。
我们特地咨询了ULINK的资深工程师,ULINK的回复如下:
We found many of the systems (OS) issues non-4K LBA. For example, Windows OS issues non-4K. JEDEC workload issues non-4K。
大多数OS下发命令不是4K对齐的,Windows就不是,JEDEC的workload也不是。
ULINK配合我们修改了脏盘测试的脚本,提供了4K对齐的选项。
下面是其中一位选手4K对齐vs不对齐情况下的IOPS对比,差了快15倍,实在亮瞎。