中午闲着没事，就来说说之前有关 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块的内容和以前一样，所以无需缓存。因为比较内容是否一样还不如直接覆盖。所以，照理说，文章中所谓的“随机填充”的写入速度应该和“连续”的一模一样。之所以会出现如此大的区别，我想应该是随机数据的生成速率照成的，也就是说在这个测试中，速度的瓶颈不是内存的速度，而是产生随机数据的速度。

引用:

原帖由 测试一下 于 2014-11-18 14:48 发表
posted by wap, platform: iPhone
楼主啥时候买tlc6啊...

已经下单了，给BF买的6，自己买的6+，到时候看看到底有啥区别。

引用:

原帖由 dboy99 于 2014-11-18 14:41 发表
lz的那贫乏的知识面就别出来现了，是打算继虚拟内存之后再增添一个头衔么

是很贫乏，我觉得我还是不能很好的解释数据，请多多指教。

引用:

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


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

数据先写入到内存，因为内存速度快，只需要0.1秒就能把400MB的缓存塞满
与此 ...

我还以为你有多高明的解释呢。那为何400MB以前，每秒速度还是不断提升的，照你的意思应该，在缓存没写满之前，速度应该是恒定的呀。

引用:

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


这叫物奴，通常是因为真实生活中很失败，只能在某一物体或品牌上找到寄托和存在感，所以有人要是敢说那东西一点不好就好比杀了他亲妈。
战区的几个极端索索，还有周围的那些极端崇拜偶像的都是这种病

请问你这种冒充书记的又是什么奴？

引用:

原帖由 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

你能解释下为什么速度变化如此之小吗？

引用:

原帖由 xphi 于 2014-11-18 15:56 发表
楼主和HKEPC都在瞎分析，这个表现和Linux的Page cache一点关系都没有。这个测试的结果相当明显，原因也很简单，熟悉SSD的一眼就能看出来，这明显是用TLC的iPhone使用了数据压缩加速技术。早期SSD上常用，当时以SandF ...

把数据压缩一下有什么好处？ 为什么只在SSD上做压缩，而发展了这么多年的普通硬盘上没采用过？

引用:

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


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

我能说你是个xx么，这么低级的问题都要反复问

count从10变到60你眼睛瞎啦看不到吗？ 看你还要装逼到什么时候。

引用:

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


小文件写一百遍还是小文件，你的逻辑我是越来越看不懂了

吓死了， 看来完全不在一个档次，你还是消停一边凉快去吧。

引用:

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


你就算完全不懂存储好歹也看看原版HKEPC的截图，看看别人的dd命令是怎么写的……

没啥区别，只不过人家是指数性增加写入量，我是线性增加写入量。

引用:

原帖由 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的数据，速度还是没什么变化。

引用:

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

还不放心可以用oflag=sync再测一遍。。。

关键是文章说测试结果是因为使用了page cache造成的，这个推理明显不合理，但是我也不知道如何解释这个测试结果，不知道为何前面400MB不断提升，然后又迅速滑坡。

引用:

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

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

假设硬盘的速度随着bs大小线性增长的，那么为了节省测试时间，可以做一个这样的 ...

你到底能不能解释为什么在400MB以内TLC的写入速度随着数据量的变大而变大？如果你说是因为缓存造成的，请解释原因。解释不了发表一些人们能听懂的讲解也可以，否则请闭嘴。

引用:

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


我说数据压缩加速由Sandforce开始，又没说只有他家才有。透密压缩如果完全靠主控，应该可以做到多大的数据写入都没有问题，但是从这篇文章的测试来看，iPhone很可能动用了主处理器来做压缩，所以才会出现原文中描 ...

把数据压缩到底有什么好处呢，写到外部存储器的数据又不会因此而减少。

引用:

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


400MB内TLC的速度其实就是缓存的速度，而缓存的速度是会随着bs的增大而提高，这逻辑够简单了吧

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