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

引用:

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


Sandforce的压缩加速又不是什么神秘技术，11年前后透明压缩的各种分析文章到处都是，你就不能自己找点资料读一下？

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


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

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

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

想多学学ssd的知识可以去pceva看看，那里大神多的是

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

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

引用:

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

引用:

原帖由 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 编辑 ]

引用:

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

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

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

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

在正常的测试中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

引用:

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


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


sandforce主控的压缩跟小文件写入有个屁关系啊，压缩是在底层用DSP实现的，不会消耗主控算力，而且跟文件层一点关系都没 ...

我说数据压缩加速由Sandforce开始，又没说只有他家才有。透密压缩如果完全靠主控，应该可以做到多大的数据写入都没有问题，但是从这篇文章的测试来看，iPhone很可能动用了主处理器来做压缩，所以才会出现原文中描述的一些奇怪的场景，比如：“但對 Random Data Copy 測試沒有什麼性能幫忙，相反令 CPU 佔用率大幅提高，導致 iPhone 6 出現沒有反應的情況。”

引用:

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

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

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

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

引用:

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


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

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

引用:

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

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

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

引用:

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


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

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

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

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

也可以说，苹果从2011年就开始为iphone6使用tlc铺路了

引用:

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

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

看懂了没？

[ 本帖最后由 xphi 于 2014-11-18 17:04 编辑 ]

引用:

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


708417

看懂了没？

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

[ 本帖最后由 ff_cactus 于 2014-11-18 17:12 编辑 ]