Board logo

标题: 说说 iPhone6 TLC 测评中的一些错误。 [打印本页]
作者: ff_cactus    时间: 2014-11-18 14:25     标题: 说说 iPhone6 TLC 测评中的一些错误。

中午闲着没事，就来说说之前有关 iPhone6 TLC 测评中的一些错误。 首先将原文贴一下。
========================================================================
稿源：MacX
有传闻称iPhone 6不仅128GB型号采用TLC，香港知名硬件网站HKEPC近日就此问题做了一次详细测试，他们找来了多个iPhone 6 64GB样本，包括太空灰，银色及金色各种颜色，而且出货日期十分接近。
结果发现，同样是iPhone 6 64GB A1586港行，出现了HYNIX(海力士)、TOSHIBA(东芝)MLC颗粒及TOSHIBA(东芝)、SANDISK(闪迪) TLC颗粒四种不同版本。
为了测试采用不同闪存颗粒的iPhone 6 64GB在磁盘性能方面是否存在差异，HKEPC使用SSH对样机进行了DD Copy测试，分为Zero Fill（全零填充）以及Random Fill（随机填充）两种方式，进行1K、4K、16K、64K、256K、1024K、4096K、8192K、32768K大小文件测试，每个文件大小重复100次。
Zero Fill（全零填充）测试：

HKEPC测试发现，采用TLC闪存的iPhone 6 64GB会针对磁盘系统进行快速存取优化，只要开启显存使用的App，当系统进行拷贝时会使用系统内存进行暂存，以提升TLC写入的系统性能，甚至出现了TLC闪存颗粒的iPhone 6 64GB进行拷贝时，性能表现超越了MLC颗粒的版本，最高写入速度高达207MB/s。
不过，但数据文件超过400MB以后，其系统性能就会出现严重的下降，前台应用甚至会出现延迟或者闪退的情况。如果采用TLC闪存的iPhene 6 64GB开启了多个消耗系统内存的App，磁盘性能下降问题会更明显，因为磁盘系统会根据内存使用情况分配快速存取硬盘的可用容量。

iPhone 6 64GB TLC NAND闪存加入了动态缓存技术


iPhone 6 64GB MLC NAND闪存没有动态缓存技术

另一方面，采用MLC闪存的iPhone 6 64GB进行文件拷贝时，系统内存并没有针对磁盘进行快速存取，但整体表现比较平均。其中，以采用TOSHIBA(东芝)MLC颗粒的性能最佳,最高写入速度达到79.2MB/s，HYNIX(海力士)MLC颗粒就要差一些，最高只有70.2MB/s。
此外，和TLC不同的是，采用MLC颗粒的iPhone 6 64GB进行文件拷贝时，系统内存使用的情况并没有太多变化，也没有因为拷贝大文件写入速度大幅下降，前台应用在拷贝时保持稳定，没有出现延迟或闪退的情况。
Random Fill（随机填充）测试：

当改用随机填充测试时，TLC和MCL的性能差距明显扩大。由于系统内存难以对细小非连续的文件继续动态存取，采用TLC颗粒的iPhone 6 64GB的写入性能大幅下降至3MB/s以下。虽然采用MLC的版本表现也不是太理想，但小文件写入都在3.5MB/s，随着文件增大，表现也会明显上升。相反，TLC由于采用动态快速存取磁盘优化，对随机拷贝测试没有帮助，相反令CPU的占用率大幅度提高，导致iPhone 6出现没有反应的现象。
内存使用：
下图是TLC闪存iPhone 6 64GB的内存使用情况，当进行文件拷贝时，内存使用率会突然大幅提升。最明显的是，Inactive部分突然由93.4MB上升到232.8MB，这些文件会被iOS暂时存在内存用作为硬盘缓存，空闲部分只有28.2MB。

下图为MLC闪存iPhone 6 64GB的内存使用情况，进行文件拷贝时，内存上升幅度明显没有TLC那么大，空闲内存也有165.1MB。

点评：
使用TLC的iPhone 6确实会在高负载文件写入时出现不稳定的情况，比如应用崩溃；
MLC颗粒的性能综合表现要更好，也要稳定的多。
祈祷自己买到MLC版本吧
由此可见，此前报道的iPhone 6/6 Plus出现死机、应用崩溃的情况客观存在，而且是可以用测试证明的。从之前的消息来看，128GB版本基本都是TLC，64GB也基本是一半一半。如果你想保险，只能选择16GB版本或者购买AppleCare了。

========================================================================

为了使得大家能看懂，我首先需要介绍一些基本概念：
1. 冯诺依曼架构的CPU只能执行在内存中的内容。换句话说，手机无论是运行应用程序、放歌看图、下载拷贝等，都需要数据至少在内存里面过一遍。ARM系列的CPU都是如此。
2. 并不需要一次性把所有数据都读取到内存中来，可以先读写一部分，当需要其他部分的时候，再腾挪出空间给新的数据。
3. 当今几乎所有的操作系统都会在内存中开辟一块区域，来缓存外部存储器的数据，所谓外部存储器就是这里说的TLC、MLC。这是因为数据经常需要重复读写，而且内存比外部存储器快得多。

接下来就可以对这上面那篇文章进行分析了。
我首先指出这篇文章上一个宏观上的测评问题，它只测试了写，没测读。这是一个非常大的问题，比我后面要说的问题要大得多。为什么呢，因为我们用手机，对外部存储器几乎全是读。应用程序我们只在安装的时候写一次。其他音乐图片书刊等，我们存好后几乎不会编辑它。删除应用程序、文件时，也只是对目录进行修改（目录里没了就认为文件删除了），并不需要把文件内容清零。所以手机对于外部存储器的读取性能要求要远远高于写入要求。而这方面的信息文章里有意无意的忽略了。我认为文章能把这个忽略，首先就说明了这测评极不专业。
然后我们再来看看文章对写数据的测与评。
首先文章说它先测的连续写。所采用的方式是用DD命令，比如
dd if=/dev/zero of=filename bs=8192K count=100
不懂这个命令含义的人我先来解释下。它就是对一个名叫filename的写数据，写入的内容8192K个空字节（0x00)，像这样做100次。请注意这里的100次，它指的不是重复打开这个文件100次，打开一次，写100次8192K个空字节。
文章给出的结论是在400MB内容以内，反倒是TLC比MLC速度快。在400MB以后，TLC速度下降明显。并且文章给出的结论是系统开辟了内存来做缓存。
首先系统开辟了内存做缓存这几乎是一定的，不是因为用了TLC才这么做，iOS、Android对所有外部存储器都会这么做。这是文章的一个常识性错误。最重要的是“否使用了内存做缓存”根本无法解释400MB内容以内TLC速度更快这一“现象”。因为假如使用了缓存，那么只要写入的数据量在缓存大小内，每秒写入速度都应该是一样快，而不是在400MB内，总数据量越大，每秒写入的数据量越大。因为每秒写入的速度照理说几乎应该取决于内存的速度。所以说文章的这个推理是站不住脚的。但是我们还是应该给测试结果一个合理的解释。一个首要问题就是数据是否真实可信。文章原文说“每个文件大小重复100次”，我认为文章的意思是说“我对100个文件做了N个字节的写入操作”，而它的测试方法是“对1个文件写了N*100个字节”。不过这个测试问题的严重程度会随着写入的数据量变大而变得不重要。但是文章中的数据显然不是多次测试给出的平均值。我们都知道在大数据的写入时，尤其是几百M几G的时候，系统的其他负荷对整个过程有明显的影响，因为这个时间很长，写入几G数据时，哪怕是PC上都要几分钟。只测试一次并不能给出一个准确的答案。

然后文章测试的“随机填充测试”，文章并没有给出测试方法，不知道所谓的“随机填充测试”到底是什么意思，我姑且认为是用随机的数据来填写文件，（也就是把前面的 /dev/zero 换成了/dev/random）。那这会有什么影响呢？很多人认为因为数据是“随机”的了，那么内存缓存应该就无法起作用了所以TLC的速度就上不去了。这个解释乍一看到时很符合实验结果。但是当我们结果缓存机制来分析一下就会觉得这也说不通。在这里我们需要简单的说一下这缓存的工作机制。首先内存缓存的学名叫(Page cache或Buffer cache)它缓存的单位不是文件，而是一个固定大小的块，你比如说一个4K大小的文件块。用一个例子来解释其工作原理，当有一个6K的文件需要写入的时候，系统首先寻找一开始的4K会是否在缓存中，如果不在就在缓存中存一份，如果在就覆盖在缓存中的。然后剩下的2K系统做同样的操作。完成后这个写入操作就部分的完成了。随后系统会在恰当的时间再讲缓存中的数据写到外部存储器中去。很重要的一点是，系统不需要区分这个4K块中的内容是什么。就刚才的例子，如果我们再重新把这个6K的文件写一次，系统不会说这个2个4K块的内容和以前一样，所以无需缓存。因为比较内容是否一样还不如直接覆盖。所以，照理说，文章中所谓的“随机填充”的写入速度应该和“连续”的一模一样。之所以会出现如此大的区别，我想应该是随机数据的生成速率照成的，也就是说在这个测试中，速度的瓶颈不是内存的速度，而是产生随机数据的速度。
作者: TG药丸    时间: 2014-11-18 14:37

posted by wap, platform: iPhone
楼主简直就是苹果用户的指路明灯，果黑们这下可以统统闭嘴了。
作者: dboy99    时间: 2014-11-18 14:41

lz的那贫乏的知识面就别出来现了，是打算继虚拟内存之后再增添一个头衔么
作者: mushroom    时间: 2014-11-18 14:45

引用:
原帖由 dboy99 于 2014-11-18 14:41 发表
lz的那贫乏的知识面就别出来现了，是打算继虚拟内存之后再增添一个头衔么
这个称号太老了，很多人都不知道，该renew一下了
作者: 测试一下    时间: 2014-11-18 14:48

posted by wap, platform: iPhone
楼主啥时候买tlc6啊...
作者: 寂静狼    时间: 2014-11-18 14:49

macx这站简直是出名的果粉网站
看过一段时间的cb应该都能看表示知投稿源了
lz现在连你祖宗都不认了？
作者: ff_cactus    时间: 2014-11-18 14:57

引用:
原帖由 测试一下 于 2014-11-18 14:48 发表
posted by wap, platform: iPhone
楼主啥时候买tlc6啊...
已经下单了，给BF买的6，自己买的6+，到时候看看到底有啥区别。
作者: ff_cactus    时间: 2014-11-18 14:59

引用:
原帖由 dboy99 于 2014-11-18 14:41 发表
lz的那贫乏的知识面就别出来现了，是打算继虚拟内存之后再增添一个头衔么
是很贫乏，我觉得我还是不能很好的解释数据，请多多指教。
作者: 燕山隐士    时间: 2014-11-18 15:03

我认为最好的办法 是把闪存颗粒从苹果上焊下来 然后放到ssd里 用ssd的主控进行测试 就明白了
作者: 江南馄饨    时间: 2014-11-18 15:03

posted by wap, platform: SONY Z1
绝逼真爱……
作者: sunix.    时间: 2014-11-18 15:08

引用:
原帖由 江南馄饨 于 2014-11-18 15:03 发表
posted by wap, platform: SONY Z1
绝逼真爱……
这叫物奴，通常是因为真实生活中很失败，只能在某一物体或品牌上找到寄托和存在感，所以有人要是敢说那东西一点不好就好比杀了他亲妈。
战区的几个极端索索，还有周围的那些极端崇拜偶像的都是这种病
作者: dboy99    时间: 2014-11-18 15:15

引用:
原帖由 ff_cactus 于 2014-11-18 14:59 发表

是很贫乏，我觉得我还是不能很好的解释数据，请多多指教。
内存和nand的写入速度有一个速度差，假如内存的写入速度是5000MB/s，TLC nand的写入速度是50MB/s，那么这个速度差就是4950MB/s了

数据先写入到内存，因为内存速度快，只需要0.1秒就能把400MB的缓存塞满
与此同时缓存部分会把数据回写到nand并清空缓存，但是速度就慢多了只有50MB/s
因为缓存的大小是固定的，当缓存满了之后iphone6只能等待缓存回写清空才能继续拷贝数据，这时拷贝速度就直接等于nand的写入速度
作者: aszx21    时间: 2014-11-18 15:15

楼主
文章中说的TLC的缓存技术不是以前常识中的计算机缓存技术
是三棒子为了降低SSD硬盘成本发明的技术
原来的没有的
然后给其他厂商给模仿去了
并且被贪便宜的库克看上
作者: aszx21    时间: 2014-11-18 15:17

另外还要纠正楼主一个错误
手机的写入不会很少的
你收微信看网页看视频
除非你的手机是断网的
否则任何收到新的信息
就是不断的在写入

[ 本帖最后由 aszx21 于 2014-11-18 15:22 编辑 ]
作者: ff_cactus    时间: 2014-11-18 15:23

引用:
原帖由 dboy99 于 2014-11-18 15:15 发表


内存和nand的写入速度有一个速度差，假如内存的写入速度是5000MB/s，TLC nand的写入速度是50MB/s，那么这个速度差就是4950MB/s了

数据先写入到内存，因为内存速度快，只需要0.1秒就能把400MB的缓存塞满
与此 ...
我还以为你有多高明的解释呢。那为何400MB以前，每秒速度还是不断提升的，照你的意思应该，在缓存没写满之前，速度应该是恒定的呀。
作者: ff_cactus    时间: 2014-11-18 15:24

引用:
原帖由 sunix. 于 2014-11-18 15:08 发表


这叫物奴，通常是因为真实生活中很失败，只能在某一物体或品牌上找到寄托和存在感，所以有人要是敢说那东西一点不好就好比杀了他亲妈。
战区的几个极端索索，还有周围的那些极端崇拜偶像的都是这种病
请问你这种冒充书记的又是什么奴？
作者: dboy99    时间: 2014-11-18 15:46

引用:
原帖由 ff_cactus 于 2014-11-18 15:23 发表

我还以为你有多高明的解释呢。那为何400MB以前，每秒速度还是不断提升的，照你的意思应该，在缓存没写满之前，速度应该是恒定的呀。
读写速度跟文件大小是相关的，如果你连这个常识都不懂就不要随便发表高论了

自己用atto benchmark测一下你的硬盘看是不是速度恒定？

知识面贫乏不是错，但是出来现就不对了
作者: xphi    时间: 2014-11-18 15:56

楼主和HKEPC都在瞎分析，这个表现和Linux的Page cache一点关系都没有。这个测试的结果相当明显，原因也很简单，熟悉SSD的一眼就能看出来，这明显是用TLC的iPhone使用了数据压缩加速技术。早期SSD上常用，当时以SandForce主控为代表，现在的SSD似乎不太用这个技术了。

数据压缩加速对全0数据具有极强的加速效果，但是对随机数据毫无作用。从这个测试的一些结果来看，iPhone在TLC的压缩加速上可能动用了主处理器和主内存，而不是像SSD那样用SSD上的主控来做这个处理。结果就是存储的时候占用主处理器和主存，而且写入太快太大的时候会来不及压缩导致性能暴跌。

[ 本帖最后由 xphi 于 2014-11-18 16:02 编辑 ]
作者: ff_cactus    时间: 2014-11-18 16:02

引用:
原帖由 dboy99 于 2014-11-18 15:46 发表


读写速度跟文件大小是相关的，如果你连这个常识都不懂就不要随便发表高论了

自己用atto benchmark测一下你的硬盘看是不是速度恒定？

知识面贫乏不是错，但是出来现就不对了
[root@workstation ~]# dd if=/dev/zero of=/tmp/filename bs=1024K count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 0.0219152 s, 478 MB/s
[root@workstation ~]# dd if=/dev/zero of=/tmp/filename bs=1024K count=20
20+0 records in
20+0 records out
20971520 bytes (21 MB) copied, 0.0415999 s, 504 MB/s
[root@workstation ~]# dd if=/dev/zero of=/tmp/filename bs=1024K count=30
30+0 records in
30+0 records out
31457280 bytes (31 MB) copied, 0.0620917 s, 507 MB/s
[root@workstation ~]# dd if=/dev/zero of=/tmp/filename bs=1024K count=40
40+0 records in
40+0 records out
41943040 bytes (42 MB) copied, 0.0821948 s, 510 MB/s
[root@workstation ~]# dd if=/dev/zero of=/tmp/filename bs=1024K count=50
50+0 records in
50+0 records out
52428800 bytes (52 MB) copied, 0.102611 s, 511 MB/s
[root@workstation ~]# dd if=/dev/zero of=/tmp/filename bs=1024K count=60
60+0 records in
60+0 records out
62914560 bytes (63 MB) copied, 0.122361 s, 514 MB/s

你能解释下为什么速度变化如此之小吗？
作者: ff_cactus    时间: 2014-11-18 16:08

引用:
原帖由 xphi 于 2014-11-18 15:56 发表
楼主和HKEPC都在瞎分析，这个表现和Linux的Page cache一点关系都没有。这个测试的结果相当明显，原因也很简单，熟悉SSD的一眼就能看出来，这明显是用TLC的iPhone使用了数据压缩加速技术。早期SSD上常用，当时以SandF ...
把数据压缩一下有什么好处？ 为什么只在SSD上做压缩，而发展了这么多年的普通硬盘上没采用过？
作者: dboy99    时间: 2014-11-18 16:10

引用:
原帖由 ff_cactus 于 2014-11-18 16:02 发表

[root@workstation ~]# dd if=/dev/zero of=/tmp/filename bs=1024K count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 0.0219152 s, 478 MB/s
[root@workstation ~]# dd if=/dev/ze ...
bs=1024K这个参数控制写入块大小，从头到尾都是1024k所以速度也差不多

我能说你是个xx么，这么低级的问题都要反复问
作者: dboy99    时间: 2014-11-18 16:11

引用:
原帖由 xphi 于 2014-11-18 15:56 发表
楼主和HKEPC都在瞎分析，这个表现和Linux的Page cache一点关系都没有。这个测试的结果相当明显，原因也很简单，熟悉SSD的一眼就能看出来，这明显是用TLC的iPhone使用了数据压缩加速技术。早期SSD上常用，当时以SandF ...
我擦，这是我今天看到的第二个神论了，可以跟虚拟内存大神的神论相媲美
作者: ff_cactus    时间: 2014-11-18 16:17

引用:
原帖由 dboy99 于 2014-11-18 16:10 发表


bs=1024K这个参数控制写入块大小，从头到尾都是1024k所以速度也差不多

我能说你是个xx么，这么低级的问题都要反复问
count从10变到60你眼睛瞎啦看不到吗？ 看你还要装逼到什么时候。
作者: xphi    时间: 2014-11-18 16:19

引用:
原帖由 ff_cactus 于 2014-11-18 16:08 发表

把数据压缩一下有什么好处？ 为什么只在SSD上做压缩，而发展了这么多年的普通硬盘上没采用过？
Sandforce的压缩加速又不是什么神秘技术，11年前后透明压缩的各种分析文章到处都是，你就不能自己找点资料读一下？
作者: dboy99    时间: 2014-11-18 16:20

引用:
原帖由 ff_cactus 于 2014-11-18 16:17 发表

count从10变到60你眼睛瞎啦看不到吗？ 看你还要装逼到什么时候。
小文件写一百遍还是小文件，你的逻辑我是越来越看不懂了
作者: xphi    时间: 2014-11-18 16:21

引用:
原帖由 ff_cactus 于 2014-11-18 16:02 发表

[root@workstation ~]# dd if=/dev/zero of=/tmp/filename bs=1024K count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 0.0219152 s, 478 MB/s
[root@workstation ~]# dd if=/dev/ze ...
你就算完全不懂存储好歹也看看原版HKEPC的截图，看看别人的dd命令是怎么写的……
作者: ff_cactus    时间: 2014-11-18 16:22

引用:
原帖由 dboy99 于 2014-11-18 16:20 发表


小文件写一百遍还是小文件，你的逻辑我是越来越看不懂了
吓死了， 看来完全不在一个档次，你还是消停一边凉快去吧。
作者: xphi    时间: 2014-11-18 16:22

引用:
原帖由 dboy99 于 2014-11-18 16:11 发表


我擦，这是我今天看到的第二个神论了，可以跟虚拟内存大神的神论相媲美
我看你是喷糊涂了吧。
作者: mushroom    时间: 2014-11-18 16:24

引用:
原帖由 xphi 于 2014-11-18 15:56 发表
楼主和HKEPC都在瞎分析，这个表现和Linux的Page cache一点关系都没有。这个测试的结果相当明显，原因也很简单，熟悉SSD的一眼就能看出来，这明显是用TLC的iPhone使用了数据压缩加速技术。早期SSD上常用，当时以SandF ...
不能解释全0最后2个测试tlc的速度下降 和 内存的区别。
这个应该是明显的cache大小在tlc和mlc上不同而造成的。
至于有没有压缩...如果有cache的话这点速度应该没必要用压缩。
作者: ff_cactus    时间: 2014-11-18 16:25

引用:
原帖由 xphi 于 2014-11-18 16:21 发表


你就算完全不懂存储好歹也看看原版HKEPC的截图，看看别人的dd命令是怎么写的……
没啥区别，只不过人家是指数性增加写入量，我是线性增加写入量。
作者: royhimura    时间: 2014-11-18 16:27

虚拟大神又出马。。。这回苹果死透了。大法已经被LZ给粉死了，自从LZ粉苹果后安卓的市占率就成了第一，我强烈建议LZ在苹果下坡路之后开始粉锤子，xiaomi和meizu还是有活下去的价值的，求你了！
作者: dboy99    时间: 2014-11-18 16:30

引用:
原帖由 xphi 于 2014-11-18 16:19 发表


Sandforce的压缩加速又不是什么神秘技术，11年前后透明压缩的各种分析文章到处都是，你就不能自己找点资料读一下？
比你看得多得多，你只知道sandforce有压缩，有听说过台湾的群联主控也是带压缩的吗？


sandforce主控的压缩跟小文件写入有个屁关系啊，压缩是在底层用DSP实现的，不会消耗主控算力，而且跟文件层一点关系都没有，不会因为压缩而降低了小文件随机速度

不光没有降低，对于可压缩的文件，压缩型主控可以根据压缩率大幅度提高读写性能

至于说为什么sandforce的4k性能都比较菜，你要明白一点是目前市面上几乎所有的sandforce主控都是sf2281，这个主控已出来三年多了，性能追不上其他新主控也是很正常的。

想多学学ssd的知识可以去pceva看看，那里大神多的是
作者: SONIC3D    时间: 2014-11-18 16:30

2张Putty图看好，一个正常的、操作系统课不怎么逃课的学生应该都能回答这个问题。。。

还不放心可以用oflag=sync再测一遍。。。
作者: ff_cactus    时间: 2014-11-18 16:32

引用:
原帖由 xphi 于 2014-11-18 16:21 发表


你就算完全不懂存储好歹也看看原版HKEPC的截图，看看别人的dd命令是怎么写的……
[root@workstation ~]# dd if=/dev/zero of=/tmp/filename bs=1K count=10
10+0 records in
10+0 records out
10240 bytes (10 kB) copied, 0.000156322 s, 65.5 MB/s
[root@workstation ~]# dd if=/dev/zero of=/tmp/filename bs=2K count=10
10+0 records in
10+0 records out
20480 bytes (20 kB) copied, 0.000138959 s, 147 MB/s
[root@workstation ~]# dd if=/dev/zero of=/tmp/filename bs=4K count=10
10+0 records in
10+0 records out
40960 bytes (41 kB) copied, 0.000169266 s, 242 MB/s
[root@workstation ~]# dd if=/dev/zero of=/tmp/filename bs=8K count=10
10+0 records in
10+0 records out
81920 bytes (82 kB) copied, 0.000295635 s, 277 MB/s
[root@workstation ~]# dd if=/dev/zero of=/tmp/filename bs=16K count=10
10+0 records in
10+0 records out
163840 bytes (164 kB) copied, 0.000444644 s, 368 MB/s
[root@workstation ~]# dd if=/dev/zero of=/tmp/filename bs=32K count=10
10+0 records in
10+0 records out
327680 bytes (328 kB) copied, 0.000781409 s, 419 MB/s
[root@workstation ~]# dd if=/dev/zero of=/tmp/filename bs=64K count=10
10+0 records in
10+0 records out
655360 bytes (655 kB) copied, 0.00145721 s, 450 MB/s
[root@workstation ~]# dd if=/dev/zero of=/tmp/filename bs=128K count=10
10+0 records in
10+0 records out
1310720 bytes (1.3 MB) copied, 0.00283099 s, 463 MB/s
[root@workstation ~]# dd if=/dev/zero of=/tmp/filename bs=256K count=10
10+0 records in
10+0 records out
2621440 bytes (2.6 MB) copied, 0.00572339 s, 458 MB/s
[root@workstation ~]# dd if=/dev/zero of=/tmp/filename bs=512K count=10
10+0 records in
10+0 records out
5242880 bytes (5.2 MB) copied, 0.0112072 s, 468 MB/s

这是我服务器上的测试结果。内存16G，所有数据应该都再缓存中。但很明显，超过300KB数据的后，写入速度基本就不变了。上面的测试可以看出就算写入50MB的数据，速度还是没什么变化。
作者: xphi    时间: 2014-11-18 16:37

引用:
原帖由 mushroom 于 2014-11-18 16:24 发表


不能解释全0最后2个测试tlc的速度下降 和 内存的区别。
这个应该是明显的cache大小在tlc和mlc上不同而造成的。
至于有没有压缩...如果有cache的话这点速度应该没必要用压缩。
虽然不知道iOS的内存管理机制与Linux有多大差别，但是不妨假定都是差不多的Page Cache机制，如果TLC的加速是由于iOS使用了特别的cache策略的话，那么对随机数据和全零数据是一视同仁的，而不会出现文中的结果。

一般我们测IO，只关注两个参数，连续读写下的峰值性能和随机读写下的IOPS（一般用4K随机读写），这里的随机读写是指在IO设备的随机位置读写，而不是指随机数据，我们看HKEPC的原文，原文在这里：http://www.hkepc.com/11911/page/3#view。

注意原文用词：Random Fill Copy Test这一节题目虽然用的Random Fill，但是第一句话就是“當拷貝改用 Random Data 後”，从这里看出原文的测试是使用随机数据填写，而不是随机读写。不知道这里是编辑有意还是无意的结果。可能是打算测随机读写，结果测成了随机数据读写。

一般的IO测试不会测随机数据读写，因为没有什么意义，但是当时SandForce主控开发出了透明压缩加速之后，对全0数据有极其强大的加速做作用，被人视为作弊，所以后来SSD测试软件都会特别使用随机数据来测试SSD性能，如果能找到老的Sandforce主控，可以试用老版的AS SSD Benchmark 和 Atto分别做测试，就能看到巨大的性能差异。

[ 本帖最后由 xphi 于 2014-11-18 16:39 编辑 ]
作者: ff_cactus    时间: 2014-11-18 16:39

引用:
原帖由 SONIC3D 于 2014-11-18 16:30 发表
2张Putty图看好，一个正常的、操作系统课不怎么逃课的学生应该都能回答这个问题。。。

还不放心可以用oflag=sync再测一遍。。。
关键是文章说测试结果是因为使用了page cache造成的，这个推理明显不合理，但是我也不知道如何解释这个测试结果，不知道为何前面400MB不断提升，然后又迅速滑坡。
作者: dboy99    时间: 2014-11-18 16:43

不得不佩服内存大神，被打脸啪啪的啥事没有继续献丑

在正常的测试中1k的文件块因为太小了，所以会适当增大count来排除缓存的影响

假设硬盘的速度随着bs大小线性增长的，那么为了节省测试时间，可以做一个这样的设定
bs=1k count=20000
bs=2k count=10000
bs=4k count=5000
bs=8k count=4000
bs=16k count=2000
。。。。
bs=1024k count=200
作者: xphi    时间: 2014-11-18 16:43

引用:
原帖由 dboy99 于 2014-11-18 16:30 发表


比你看得多得多，你只知道sandforce有压缩，有听说过台湾的群联主控也是带压缩的吗？


sandforce主控的压缩跟小文件写入有个屁关系啊，压缩是在底层用DSP实现的，不会消耗主控算力，而且跟文件层一点关系都没 ...
我说数据压缩加速由Sandforce开始，又没说只有他家才有。透密压缩如果完全靠主控，应该可以做到多大的数据写入都没有问题，但是从这篇文章的测试来看，iPhone很可能动用了主处理器来做压缩，所以才会出现原文中描述的一些奇怪的场景，比如：“但對 Random Data Copy 測試沒有什麼性能幫忙，相反令 CPU 佔用率大幅提高，導致 iPhone 6 出現沒有反應的情況。”
作者: ff_cactus    时间: 2014-11-18 16:48

引用:
原帖由 dboy99 于 2014-11-18 16:43 发表
不得不佩服内存大神，被打脸啪啪的啥事没有继续献丑

在正常的测试中1k的文件块因为太小了，所以会适当增大count来排除缓存的影响

假设硬盘的速度随着bs大小线性增长的，那么为了节省测试时间，可以做一个这样的 ...
你到底能不能解释为什么在400MB以内TLC的写入速度随着数据量的变大而变大？如果你说是因为缓存造成的，请解释原因。解释不了发表一些人们能听懂的讲解也可以，否则请闭嘴。
作者: ff_cactus    时间: 2014-11-18 16:52

引用:
原帖由 xphi 于 2014-11-18 16:43 发表


我说数据压缩加速由Sandforce开始，又没说只有他家才有。透密压缩如果完全靠主控，应该可以做到多大的数据写入都没有问题，但是从这篇文章的测试来看，iPhone很可能动用了主处理器来做压缩，所以才会出现原文中描 ...
把数据压缩到底有什么好处呢，写到外部存储器的数据又不会因此而减少。
作者: dboy99    时间: 2014-11-18 16:52

引用:
原帖由 ff_cactus 于 2014-11-18 16:48 发表

你到底能不能解释为什么在400MB以内TLC的写入速度随着数据量的变大而变大？如果你说是因为缓存造成的，请解释原因。解释不了发表一些人们能听懂的讲解也可以，否则请闭嘴。
400MB内TLC的速度其实就是缓存的速度，而缓存的速度是会随着bs的增大而提高，这逻辑够简单了吧
作者: ff_cactus    时间: 2014-11-18 16:54

引用:
原帖由 dboy99 于 2014-11-18 16:52 发表


400MB内TLC的速度其实就是缓存的速度，而缓存的速度是会随着bs的增大而提高，这逻辑够简单了吧
你不说缓存的速度约等于内存的速度吗，还能不断变快？
作者: dboy99    时间: 2014-11-18 16:59

把iphone6的慢归咎于压缩是完全错误的，平时关注SSD的人应该都听说过苹果当年收购anobit吧，ip6就是用的他的主控，而anobit从来都没有声称过他们的主控具备压缩功能。至于说依靠CPU来做压缩就更可笑了，MLC版ip6的小文件读写没有受影响就证明苹果没有使用CPU做压缩。

anobit这家小公司的长项是在于通过特殊的信号处理和纠错算法大幅度提高nand的寿命，苹果也是看中了这一点才会花5亿美金收购这家小公司。

也可以说，苹果从2011年就开始为iphone6使用tlc铺路了
作者: xphi    时间: 2014-11-18 17:01

引用:
原帖由 ff_cactus 于 2014-11-18 16:54 发表

你不说缓存的速度约等于内存的速度吗，还能不断变快？
[attach]708417[/attach]

看懂了没？

[ 本帖最后由 xphi 于 2014-11-18 17:04 编辑 ]
作者: ff_cactus    时间: 2014-11-18 17:11

引用:
原帖由 xphi 于 2014-11-18 17:01 发表


708417

看懂了没？
你到底是想通过本质解释现象，还是想通过现象解释现象？ 确实没看懂。 我又没说文章的数据在造假， 我质疑的是数据的解释。你把实验再做一次能解释什么？

[ 本帖最后由 ff_cactus 于 2014-11-18 17:12 编辑 ]
作者: xphi    时间: 2014-11-18 17:17

引用:
原帖由 dboy99 于 2014-11-18 16:59 发表
把iphone6的慢归咎于压缩是完全错误的，平时关注SSD的人应该都听说过苹果当年收购anobit吧，ip6就是用的他的主控，而anobit从来都没有声称过他们的主控具备压缩功能。至于说依靠CPU来做压缩就更可笑了，MLC版ip6的小 ...
我的推测是iPhone只在TLC的存储上使用主处理器进行透明压缩来节约闪存寿命和改善性能，这是参照文章的内容来分析的结论，可以解释文中所有结果。MLC版的小文件有没有读写性能下降与我的推测有啥关系？

而所谓的Cache不能解释为什么TLC版的对随机数据性能极差，如果使用Cache机制，TLC在使用随机数据和全零数据时会具有同样曲线。

更进一步来说，原文在测试400MB数据写时，TLC版的iPhone做到了持续性能200MB/s，而在800MB数据写时性能暴跌。如果这是使用Cache机制导致，至少说明两点，1、iPhone6可以划分出至少400MB以上内存供IO用作Cache；2、iPhone6的内存性能只有200MB/s。这两点看起来都很不可能。
作者: xphi    时间: 2014-11-18 17:18

引用:
原帖由 ff_cactus 于 2014-11-18 17:11 发表

你到底是想通过本质解释现象，还是想通过现象解释现象？ 确实没看懂。 我又没说文章的数据在造假， 我质疑的是数据的解释。你把实验再做一次能解释什么？
dd有个参数可以设置oflag，去man一下看看是啥意思。
作者: ff_cactus    时间: 2014-11-18 17:27

引用:
原帖由 xphi 于 2014-11-18 17:18 发表


dd有个参数可以设置oflag，去man一下看看是啥意思。
你的测试最多只能解释为什么400MB那里为什么会有一个巨大的滑坡。问什么随机数据填写没有呢。
作者: ff_cactus    时间: 2014-11-18 17:32

总之吧，这篇测评问题颇多。
最严重的问题我也说了，居然连最重要的读取速度都没测。如果依照这篇文章的数据，我反倒觉得在绝大多数的情况下TLC更有优势。某些应用程序奔溃也不应该是缓存管理的原因，毕竟相关算法等已经相当成熟，不至于造成系统奔溃。以后TLC反倒是趋势了。
作者: xphi    时间: 2014-11-18 17:33

引用:
原帖由 ff_cactus 于 2014-11-18 17:27 发表

你的测试最多只能解释为什么400MB那里为什么会有一个巨大的滑坡。问什么随机数据填写没有呢。
我再引一遍你的问题：
引用:
原帖由 ff_cactus 于 2014-11-18 16:54 发表

你不说缓存的速度约等于内存的速度吗，还能不断变快？
我截图是告诉你这个问题的答案。

至于原文的测试结果，我第一帖就解释了。
作者: ff_cactus    时间: 2014-11-18 18:10

posted by wap, platform: iPhone
引用:
原帖由 @xphi  于 2014-11-18 17:33 发表
我再引一遍你的问题：

我截图是告诉你这个问题的答案。

至于原文的测试结果，我第一帖就解释了。
你的截图解释了为什么会越来越快了？



欢迎光临 TGFC Lifestyle (http://bbs.tgfcer.com/) Powered by Discuz! 6.0.0