本帖最后由 Asuka 于 2015-3-26 23:35 编辑
所谓买贵的不如买对的 (应用篇)
典型应用1：软路由 小小机器，两张小螃蟹网卡两个网口，1LAN，1WAN，10W功耗，不知道的还以为是X米路由，X雷路由还是极X由呢。可是我们有颗x86的心脏，充裕的内存，海量的硬盘空间（啥，X米有1T？醉了）。
这次我们还是请出Asuka最熟悉的x86平台路由系统pfSense。作为对比的是躺在Asuka家里大材小用做AP的Linksys EA6500官方固件。本次测试的大致方案如下，
目标：路由器的LAN-WAN, WAN-LAN, 及同步处理能力 拓扑：电脑A——LAN~WAN——电脑B 预设置：测试端口的映射 测试时长30秒，速度采样频率1秒 传输层协议：TCP Parallel Streams，并行数据流数：5（用以跑满峰值） 软件：jperf 备注：每一家媒体机构，不同的测试方法环境都会对测试结果产生影响，所以Asuka只能保证在我提出的这种框架下的测试才具有一定可比性，同时保证一定的统计可靠度。（其实就是我懒得去找IxChariot） 首先让我们从pfSense开始测起吧！
pfSense LAN to WAN throughput 30sec： 传输资料统计：[SUM] 0.0-30.0 sec 总传输数据量2888 MBytes 平均带宽807 Mbits/sec
pfSense WAN to LAN throughput 30sec： 传输资料统计：[SUM] 0.0-30.0 sec 总传输数据量2791 MBytes 平均带宽780 Mbits/sec
然后是EA6500，第一代802.11ac无线路由器，如今虽有些廉颇老矣，但仍然是中高端路由器的代表性能。本次测试全程关闭WiFi以减少干扰。结果如下， EA6500 LAN to WAN throughput 30sec： 传输资料统计：[SUM] 0.0-30.0 sec 总传输数据量2498 MBytes 平均带宽698 Mbits/sec
EA6500 WAN to LAN throughput 30sec： 传输资料统计：[SUM] 0.0-30.0 sec 总传输数据量2934 MBytes 平均带宽820 Mbits/sec
测试数据小汇总：
在Asuka设计的实验条件下，软路由和EA6500的表现基本差异不大，可惜Asuka并没有更加高级的路由，也没有测试其他固件系统的传输能力，很是遗憾啊！说实话，做这个测试的过程真的异常烧脑，Asuka是那种很懒得做笔记做计划的人，完全靠大脑要全部理顺还真是不太容易的事呢！但是和这个单纯的单向传输测试相比，以下的同步测试更是复杂了一些，且听Asuka慢慢介绍。
同步测试，亦即上下行同时发生时，路由器的处理能力，相比之前的测试，该测试更加贴近实际。所以Asuka设计了如下方案，基于这样一个场景，混PT的朋友可能出现的一种极限状况，熟悉的站友应该了解，混PT大部分时间是在混上传，但偶尔也会同时进行一些下载。所以Asuka是这样设计的，让路由器LAN to WAN上行一样跑五路数据流30秒，同样每秒采样一次，在进行过程中，突然释放五路WAN to LAN的下行数据流，测试20秒，同样每秒采样一次。最终呈现路由器在上下行同步高负荷运行时的输出能力。
首先同样是从pfSense。
pfSense spontaneous LAN to WAN throughput 30sec: 传输数据统计[SUM] 0.0-30.0 sec 总传输数据量2232 MBytes 平均带宽624 Mbits/sec
可以看见中间曲线下坠时下行数据流触发。最终测试到：
pfSense spontaneous WAN to LAN 20sec: 传输数据统计[SUM] 0.0-20.0 sec 总传输数据量1101 MBytes 平均带宽461 Mbits/sec
同样的测试用EA6500跑跑看。
EA6500 spontaneous LAN to WAN throughput 30sec: 传输数据统计[SUM] 0.0-30.0 sec 总传输数据量1653 MBytes 平均带宽462 Mbits/sec
pfSense spontaneous LAN to WAN throughput 30sec: 传输数据统计[SUM] 0.0-20.0 sec 总传输数据量826 MBytes 平均带宽346 Mbits/sec
再进行一次实验数据统计。
首先，需要解释的是，有些站友可能会问，为什么上行测试的呈现数据是整个30秒的，而不是真正同步运行中的20秒呢？Asuka认为，首先为了模拟用户平时的使用习惯，下行是Asuka手动开始的，亦即下行数据采样时间点与上行数据采样点是不重合的，所以忽略了任何一个采样点的个性，整个的测试过程反而有其统计可靠性。所以，好吧，其实根本就是我懒，哈哈哈！
我想结果呈现已经非常明确了，arm架构的处理器终于露出了瓶颈，处理能力的巨大差异终究开始体现出来了。如果再加上QoS的参与，翻墙插件，VPN插件的使用，arm-based处理器的性能瓶颈将会更加暴露在用户眼前。而我们的x86软路由，即便是在上下行同步满载的时候，其实也只用了30per左右的处理能力而已，说实话我觉得无论我如何提升测试的难度，甚至是跑到网卡的极限都无法充分调动J1900的处理能力吧！话说回来，我们又为啥要买Celeron，Pentium甚至是core的处理器呢？我们真的有调动那么大的运算力吗？我们真的没有浪费多余的钱或者电力吗？希望大家和我一起思考。
典型应用2：HTPC
大家应该还记得这台小东西的尺寸吧，不过就是两只手机的大小而已，装上Wi-Fi模块以后做HTPC绝对没有问题，只是那工业设计咱们就先略去不表吧！首先向大家介(xuan)绍(yao)一下Asuka的客厅吧！
茫茫多的设备，说实话不注意的话可能都找不到咱们小巧的主角呢！唯一Asuka难以释怀的点在于Asuka家里的功放说实话真是有些年数了，唯一拥有的SPDIF输入口就是光纤——Toslink (Short for Toshiba Link)。想来就是因为这个接口的授权问题吧，大量的NUC都没有提供光纤输出接口，到目前为止，Asuka只注意到之前论坛评测的ASUS VivoPC有配，而技嘉Brix只提供同轴的SPDIF输出，让Asuka这老旧的设备情何以堪，泪。当然，要实现光纤输出还是可以通过USB声卡的，这个地方Asuka对这台小设备的第二个诟病也就来了，USB全部在前方是要怎样啊！如果Asuka想拿来接声卡接光纤，那岂不是得从前面板拉线到后面去，那真是丑得一B了。
废话略去不表，如今HTPC真的有点被各种盒子压住了呢！Asuka之前也进了一台X美迪，那宣传有多屌Asuka就不赘述了。结果拿来第一天就退货了，Asuka真不是故意黑，X美迪真的做得东西不错的，但是Asuka为什么有意见呢？原因在于，Asuka想拿来跑Kodi (以前叫做XBMC)，开源的，自己可以mod，还有很好的手机平板遥控器程序，用习惯了。所以Asuka就装了kodi在X美迪上，一看分辨率，尼玛720P是要怎样？还不能调。查了以后才发现，原来盒子的安卓系统UI只有720P，意味着所有安卓应用恐怕都突破不了这个底层分辨率的瓶颈，赶紧退货了。那是，一千块就能买一台小PC，谁还要你那些阉割盒子啊！贵的盒子那价格也低。
这里就介绍一下Asuka的HTPC解决方案，Kodi有一个兄弟计划，叫做OpenELEC，Open Embedded Linux Entertainment Center。其实就是一个最底层的Linux系统整合了Kodi而已。非常适合做HTPC之用，如果你想问性能如何，我就说树莓派都能跑x86不能跑吗？对吧，安卓盒子都得靠处理器硬解来对付部分麻烦的片子，x86咱尽管来，没事儿！Asuka拍了一小段视频展示这套系统的开关机速度，大家直观感受就明白了。AirPlay，DLNA，各种应用谁用谁知道。
非典型应用：NAS
之所以称作非典型应用，主要是Asuka觉得没人会用这台小设备做NAS的，嗯嗯。所以NAS应用只能算是Bay-Trail平台广义应用中的一种。Asuka虽然给这台小东西装了OpenMediaVault，但也只是测了个功耗给大家做参考。一样，10W平台功耗，大家如果真的自组NAS那多少块硬盘多少电，大家可以自己算账啦！
从Asuka前面写的大家就可以看到了，硬件还是那个硬件，应用却像一片海洋，我们需要的只是去捕捞自己想要的应用，不喜欢Kodi可以装Plex，OpenMediaVault不够，可以加Subsonic模块做音频串流，反正都是基于Debian。
硬件是单纯的，一分钱一分货，摩尔定律走到今天，硬件真的越来越乏味而不值钱了。我们又该何去何从，这是整个产业都面临的问题，Asuka今天想表达的只是一种最简单的突破，more than Moore。一台小盒子，可以是路由器，可以是HTPC，可以是NAS，可以是串流设备，还可以是无穷无尽的可能，只要你可以看到单纯硬件做支撑的不凡，相信你也会发现，哪怕只是这一台最入门的小设备，都可以带给你莫大的快乐！大概，这就是论坛所谓买对不买贵，所谓折腾的快感吧！只要你有心，咱装个Android？
| 
能路由和HTPC合体就好了
