本篇文章来聊聊搭载了 Marvell ARMADA A3720 CPU 的小巧设备“猫盘”，在下载场景的实际表现。
网络上关于这台设备的折腾记录，诸如刷机换系统、甚至是硬改 USB 接口等攻略有很多了，然而对于它在下载场景性能相关的记录却非常少。所以，本篇文章着重聊聊大量数据下载场景时的设备性能状况，供有类似下载需求和类似硬件的小伙伴参考。
写在前面
相信电子产品爱好者家里总会有几块闲置的硬盘，这些磁盘可能是你从笔记本上替换下来的，也可能是你曾经使用过的移动硬盘，还可能是曾经为你服务过的 NAS 磁盘。
这些磁盘或因为容量、或因为性能、甚至因为和相对昂贵的 NAS “盘位费” 对比太过“廉价”，放在 NAS 中显得性价比低而被闲置。
如果将这些闲置磁盘挂网上进行二手处理，由于当前硬盘市场环境、以及机械硬盘怕震怕摔的“敏感体质”，过程中难免会遭遇一些“小麻烦”，出售者需要和购买者解释交代磁盘的“前世今生”、还可能需要处理因为快递运输过程导致的磁盘损坏产生的售后问题，甚至还会有人一上来就询问你是否用这磁盘“挖过矿”，挨着跟陌生人解释着实比较麻烦。
如果是全新的设备，你实在用不着，我建议你可以送给你的朋友，让它作为移动硬盘继续“发光发热”；如果是已经使用过的设备，或许给他一个适合的“安身之所”有机会继续工作，才是更好的选择？有一些朋友，或许和我遇到了类似的问题，很多时候免不了有各种下载的需求，但是又不希望长期在自己的主 NAS 上跑这些任务，因为一来磁盘成本挺高的，持续下载还是蛮伤磁盘的，会缩短硬件使用时长，二来如果发生硬件损坏，大容量磁盘折腾一次数据迁移耗时巨长。
所以，如果能将这些闲置磁盘放在低功耗的设备上执行我们所需要的数据下载任务，岂不妙哉？
为什么选择“猫盘”
闲置磁盘资源就绪后，选择运行下载任务的设备就显得很重要了，作为辅助设备，除了考虑成本之外，我们还是需要关注下性能、以及一丢丢的扩展性和易用性。
我曾考虑过用前些年支持挂载磁盘的路由器（内置 SATA 接口或支持通过设备的 USB 口连接磁盘），但是这类设备功耗控制虽好，硬盘读取写入速度太差，多数方案都还是基于 Aria 等相对老牌的工具，对于常见的诸如百度网盘类的资源下载需要借助额外的工具和服务，性能不够好，使用体验上不够易用。
我也曾考虑过使用家里低功耗的 NUC7、或者使用 NUC8 上的 ESXi ，或者之前文章中提到的“家用服务器”跑个专门用于下载的系统，性能绝对足够，觉得什么不好用，随便改改重新编译运行就是了，然而这样可能会对原本运行的好好的服务造成影响。相比较集成在原有的硬件上，我更希望这是一台独立的小设备。
群里有不少同学有推荐过两款出名的“矿渣”，作为一个“颜控” + “迷你设备爱好者”，我最终将目标聚焦在了去年曾火过的设备“猫盘”上：比 2.5 寸硬盘大不了多少的圆盘形设计，搭配使用低功耗的 ARM CPU，支持刷机运行 Debian 或者 Ubuntu，如果你愿意折腾，它也能运行“群晖”系统。内置一个 2.5 寸 / 3.5寸磁盘位，让它不需要使用 USB 外接硬盘盒来对接磁盘使用。当然，如果你有这个需求，也可以自己添加一个 USB 口，用于外挂硬盘。
对了，猫盘的设备外壳非金属，长时间挂机使用建议放在比较开阔的环境，它的外壳材质容易粘灰尘，强迫症患者需要自我克服一下。
考虑到易用性，接下来我们直接用猫盘运行“群晖”系统进行测试，来看看在三种不同场景下这个设备性能发挥如何。测试过程中搭配的是一块运行了 2 万多小时的老硬盘：HGST 7200 转机械磁盘。至于网络环境则是一条千兆的家庭宽带，确保下载瓶颈不在网络请求发起处。
对了，如果你对上文中提到的 Aria 感兴趣，可以翻阅 《更好的 Aria2 容器化使用方案》；如果你也需要在 Nuc 设备上安装 ESXi，可以翻阅《NUC 折腾笔记 - 安装 ESXi 7》。
设备在下载场景的具体表现
截止本文撰写时，设备已经运行一天有余，算上这两日看哔哩哔哩等视频网站，路由上显示跑了 1.5 TB 左右的数据，应该对设备做预热和测试算是比较充分了。
那么，先来看看设备在国民网盘 “百度网盘” 下载场景中的表现如何。
百度网盘下载场景
为了避免各种干扰，我清空掉了 Cloud Sync 之前所有的配置，重新进行配置并关联了百度云盘。
在等待设备持续下载 50g 左右数据后，对设备进行了简单观察。
可以看到 CPU 占用率还是蛮高的，个别时刻能够吃满 CPU，不过换句话说，这个性能用来同步百度云性能刚刚好。至于网络和存储 I/O 资源，看起来则富裕的多，因为各种众所周知的原因，百度网盘的持续下载速度其实很难保持稳定（除非是稳定的慢）。我个人觉得能够持续超过 10MB/s 的下载已经很好了，更何况实战情况下远超这个数据，这还要啥自行车啊。
当我们切换到 CPU 选项卡里继续进行观察，可以看到设备 CPU 资源使用的“满满当当”的，不过即使如此，从面板处可以看到，还是有 30% 的性能浪费在了 IO 等待上。（机械磁盘太慢，跟不上网速）
而切换到 “I/O” 选项卡，可以看到下载速度中位数在 60MB/s 左右，偶尔峰值能在 90MB/s 左右晃荡，当然也有掉速到 15MB/s 或者更低的时候，因为网络不是持续高速吞吐，所以磁盘自然也有了喘息的时间，非持续峰值的时候，写入压力并不算大。
在测试过程中，设备温度由 42 度升到了 47 度，整体来看状况还是比较好的。
HTTP 下载场景
原本想测试一个“大块头”的游戏客户端，但是现在的游戏厂商考虑成本和可维护性，都使用了自带的客户端提供下载。所以只好退而求其次，使用一个体积文件体积相对小，但是普适度更高的样本来做下载分析：从微软官方网站下载 Windows 光盘镜像。
相信你一定也遇到过从一些网站使用 HTTP 方式下载资源的场景。相比较我们熟悉的 P2P 下载，这种下载方式完全看对方网站 / CDN的带宽能力，而带宽 / 流量实际成本其实还是蛮高的，尤其是“大水管的带宽费用”高到令人乍舌（感兴趣可以自行了解下），所以一般情况下服务提供商会限制用户下载所使用的峰值带宽，避免单一用户占满带宽，在提供服务的过程中尽可能降低运营成本。
因为下载速度的上限由这个内容提供商来确定，并且多数情况下会限制为一个比较低的数值，所以除非我们同时进行非常多的下载任务，否则这台小设备不会感受到运行压力。
放大图表看 CPU 性能使用，如上文提到的，几乎没有压力。所以，在实际使用过程中，如果有多个 HTTP 来源的下载需求，不妨同时多运行几个任务，让设备得以更充分的运行，让下载总的完成时间能够更早一些。
网络流量记录也如同之前所述，刚开始时候在 20MB/s 左右，随后遇到了网站的限速，最后发生了常见的下载问题，最后的文件分块接收速度下降。因为下载速度比较慢，磁盘整体压力比较小，这里不就放磁盘 IO 相关的图了。
BT / P2P下载场景
原本计划使用 BT 下载体积庞大的“魔兽世界”客户端来验证性能，然而同 HTTP 下载场景中提到的，魔兽世界也早已去掉了这个下载选项，只好再次退而求其次，再来下载一个系统镜像吧。在 HTTP 下载场景中，我们使用了 Windows 的镜像，那么在 P2P 下载场景中，就使用一个 Linux 系统镜像好啦。
一般来说，测试的文件比较小巧（1G左右）会带来性能观测上的不准确，不过由于 BT 多点连接的特点，我们可以清楚的看到机器 CPU 负载陡然上升，以及瞬发高速吞吐带来的明显的磁盘和网络压力，甚至在观察的细致一些，你会发现相比较 HTTP 下载，内存的使用也更多了一些，即使这个文件只有 HTTP 下载的镜像的 1/5 大小。
放大 CPU 使用状况，和 HTTP 下载不同的是 I/O 等待占比更低，CPU 利用率更高一些。当然，CPU 更加物尽其用带来的是系统负载多了一倍有余。所以如果你下载的是热门资源，提供资源的节点非常多，考虑到设备持续稳定运行，建议还是尽可能减少一些同时下载的任务。
因为 P2P 下载使用的是众人拾柴火焰高的方式，所以我们不会再受到单一节点限速而导致下载速度过慢，而且因为文件切块粒度更小，在正在下载过程上速度的发挥会有额外的优势。观察图片可以看到 P2P 下载速度变化过程和 HTTP 完全不同，多数时间没有遭遇限速，即使遇到降速，也会通过迅速切换节点来尝试重新提速，整个过程一直保持着比较高的速度进行着。
在磁盘选项卡的图中，我们能够看到磁盘在下载过程中一直保持着和网络 IO 几乎对等的读写压力。所以如果你考虑挂 BT 下载，建议还是使用闲置以及未来不计划再使用的硬盘设备，提前做好“风萧萧兮易水寒，硬盘一去兮不复返”的准备。
内网回传性能表现
有些数据在下载之后，我们会考虑转移到 NAS 或者移动硬盘中保存，为了避免 NAS 中 SSD 缓存对测试造成影响，也为了避免猫盘孱弱的 CPU 在复杂协议中浪费性能从而影响发挥，我采用将“猫盘下载数据转移至另外一台群晖的外接移动硬盘中”的方式进行测试，测试数据量在 400g 左右，转移方式为在另外一台设备中使用 FTP 协议挂载远程目录，整体测试时间在一个小时左右。
下面这张图是传输过程中的设备概况，由于 FTP 传输模式过程中会有许多“休息”（切换目录）的过程，所以面板数据看起来并未满千兆，实际传输过程中的数值会高于概览。从 CPU 和内存消耗的图表来看，设备运行状况还是非常稳定的。
还是先放大 CPU 图表进行观察，因为设备功耗比较低（计算能力属于勉强够用的），所以在涉及计算的时候 CPU 使用率就会激增，这也是图表中有很多细小的毛刺的原因会看到非常多毛刺。好在设备总体资源利用率都在安全范围内，没有持续的满载运行。
另外，从图中面板可以看到，设备有 40% 的时间花在了 I/O 等待上，所以如果再挂一块磁盘，或者使用闲置的 SSD，整体资源的利用率会更好一些。
前文提到了因为 FTP 模式在下载数据过程中，会出现非常多的“休息”间隔，而且每个文件的尺寸都略有不同，甚至混杂不少碎文件，所以你会在下面的图表上看到非常多的山峰和山谷。
只有遇到尺寸比较大的文件，才能够让这个设备的传输速度跑起来，能够看到持续传输速度的中位数在 60 MB/s 左右，峰值在 90+ MB/s，偶尔瞬间速度能够达到 130MB/s+。
此外，在持续传输数据的一个小时里，磁盘温度从最初的 40 度逐步上升到 47 度，在停止任务后的十分钟左右，磁盘温度降低回了 42 度，就整个测试结果来说，我还是比较满意的。
最后
如果你并没有文中提到的下载需求，我不建议你入手这个设备，因为这个设备的 CPU 实在是有点弱，正如文中反复提到的，“将将好”在下载场景够用，如果你想跑一些复杂的计算或者使用它干一些比较重型的活，恐怕即使跑起来了，长时间运行的话，稳定性也堪忧。
如果你本身手里就有类似性能的主机设备和磁盘，也有文中提到的下载需求，那么看罢本文，或许你可以给你的设备一个“再战沙场”的机会。
–EOF