自SolidRun发布HoneyComb开发套件以来，已经过去了将近一年的时间。我记得曾经读过有关发布的Mini-ITX Arm工作站板的想法，并认为“这是个好主意”。然后我看到了价格，意识到这不仅仅是Raspberry Pi的另一个杀手.。目前该价格为750美元，加上运费和关税。像HoneyComb这样的利基设备不能像更简单的Pi那样大量生产，并且它们包装了相当多的高端技术。最终，COVID锁定无聊让我受益匪浅，于是我建立了自己的团队。再加上一个盒子和一个RAM，最终造价约为1100美元，运往伦敦。这是对我的经验的回顾，以及在这种有趣的硬件上使用Fedora的当前状态。
首先，该板所包含的技术令人印象深刻。它不会在性能上杀死Xeon工作站，但会在性能/瓦特效率方面产生重大影响。本质上，这是一台小型笔记本电脑的功能强大的服务器。它也是计算和网络功能的强大混合体，将载板中的强大网络功能与模块化子卡相结合，该子卡具有16核A72和2个具有ECC功能的DDR4 SO-DIMM插槽。载板有几个版本，可灵活交换或升级RAM + CPU选项。我购买了下图所示的版本，该版本具有16核，32GB（非ECC），512GB NVMe和4x10Gbe。如果您要为一个小国家/地区构建5G部署或ISP（在面板右下方），则可以额外支付250美元来添加100Gbe选项。
当我订购时，我并不完全理解恩智浦附带的网络协处理器。恩智浦是一家为此制造独特的LX2160A CPU / SOC以及可配置端口和卸载引擎的公司，这些引擎能够处理高达150Gb / s的网络流量，而不会占用大量CPU资源。这是NXP的Layerscape用户手册中的选项列表。
在交换机，LAG，MUX模式或直接NIC中配置端口。
我在家中的阁楼上通过Ubiquiti ES-16-XG有一个10gb的网络，所以我很想知道该板能推动多少。我也有一个通过10gb连接的QNAP，它很少能使线路饱和，所以这也可以替代NAS吗？原来，我需要整理驱动程序并首先获得稳定的安装。由于董事会已经任职一年，所以我有一些工作要做。SolidRun在Developer-Ecosystem上保持活跃的Discord，这对安装很有帮助，因为安装并不像以前的博客所提到的那样简单。我一直被人诅咒。如果您曾经看过Pure Luck，那么我注定会遇到各种硬件故障。
对于初学者，您可以添加GPU并以图形方式进行安装，也可以通过USB控制台进行安装。我从一个备用GPU（Radeon Pro WX2100）开始，打算建造一个无头盒子，最终使事情变得过于复杂。如果您需要交换零件或通过microSD卡重新刷新BIOS，则需要交换显示器，键盘和鼠标。混乱。只需插入微型USB控制台端口并通过/ dev / ttyUSB0访问它，即可获得画中画体验。拥有开放式PCIe3-x8插槽确实很棒，但我现在将其保持打开状态。请注意，该主板不支持PCIe Atomics，因此某些设备可能存在兼容性问题。
有趣的来了。此处未内置BIOS。您需要建立从源到您的RAM速度，并通过microSDHC安装。乍一看这很烦人，但随后您意识到，使用可移动BIOS安装程序很难将其固定。不错。好消息是最新的UEFI版本对我来说效果很好。请记住，每次重新刷新BIOS时，都需要重新设置所有内容。这足以从USB启动Fedora aarch64。该评估板提供64GB的eMMC闪存，您可以根据需要安装该闪存。我立即对其进行测试，发现它的读取速度约为165MB / s，写入速度为55MB / s，这对于嵌入式使用来说是实用的速度，但是我肯定会安装到NVMe。我在以前的Linux机器上有一个较旧的Samsung 950 Pro备件，但是即使使用广泛记录的内核参数解决方法，我也遇到了主要问题：
nvme_core.default_ps_max_latency_us = 0最后，我升级了主工作站，以便可以将其现有的Samsung EVO 960重新用于HoneyComb，后者的性能要好得多。
经过一番烦恼之后，我能够安装Fedora了，但是很明显，集成网络端口仍然无法与主线内核一起使用。恩智浦技术很棒，但是需要自定义内核构建和工具。一些较早的博客使用工作正常的USB-> RJ45以太网适配器解决了这个问题。希望不久将获得网络支持，但现在我从Discord上有用的工程师那里获取了内核SRPM。使用自定义内核，1Gbe NIC可以正常工作，但事实证明SFP +端口需要更多配置。在您使用NXP的restool实用程序将端口映射到其用法之前，它们不会被识别为接口。在这种情况下，仅是dmap-> dni的运行时映射是必需的。这是恩智浦通过IOCTL命令将MAC映射到网络接口的方式。也没有提供restool二进制文件，必须从源代码构建。然后在管理脚本上分层，这些脚本使用厚脸皮的$ arg0引用进行重定向，以使用复杂的参数调用restool二进制文件。
自从我开始积累大量自定义软件包以来，很明显，需要COPR回购来简化Fedora的工作。如果您不熟悉COPR，我认为这是Fedora最好的资源之一。此存储库包含uefi构建（当前正在失败的构建），具有网络支持的5.10.5内核以及具有支持脚本的restool二进制文件。我还添加了一个oneshot systemd单元以在引导时启用SFP +端口：
systemd enable --now dpmac@7.service
systemd enable --now dpmac@8.service
systemd enable --now dpmac@9.service
systemd enable --now dpmac@10.service现在，每个SPF +端口将启动配置为eth1-4，其中eth0为1Gb。除非这些保持一致，否则NetworkManager会苦苦挣扎，如果您更改服务启动顺序，则eth设备将重新排序。实际上，我在每次激活时都设置了一个睡眠$ @，因此它们是一致的，并且没有锁定问题。不幸的是，它增加了10秒的启动时间。此问题已在最新内核中修复，一旦成为主流后就不会成为问题。
我很想探索内置的LAG功能，但这仍然需要编码到
Restool选项。我将其保存以备后用。在此期间，我主要管理了一个10gb链接和一个3×10 LACP团队进行踢球。最终，我通过安装在阁楼上的铜SFP +电缆更改为4×10 LACP。
能源效率
现在有了一个稳定的环境，是时候引起一些麻烦了。很高兴看到最近为CPU风扇添加了PWM支持，这听起来像是没有它的微型喷气发动机。现在，声音水平可以完全控制，并且热控制是自动的。是时候使用功率计来测试驱动器了。总功率使用量始终在20至40瓦之间（通常在20秒以下），这确实令人印象深刻。我尝试了一些调整后的配置文件，这些配置文件似乎对能量没有太大影响。如果您添加了可以显着增加功耗的GPU或设备，但是对于开发服务器而言，它是完美的，并且远低于Z600工作站，我旁边是Z600工作站，启动时每台的功耗为160-250瓦。
远程访问
我是个老灵魂，所以我仍然更喜欢通过X2go服务器将KDE与Xorg和NX配合使用。我可以在没有GPU的情况下以本机性能访问SSH或完整的GUI。这使我对性能，热量统计有感觉，还有助于评估该设备是工作站还是潜在的VDI。aarch64服务器自旋附带的KDE版本似乎无法识别某些传感器，但这似乎是因为我必须深入研究KDE最新的小部件更改。
通过SSH的X2go KDE会话
开箱即用的支持也很出色。如果您不希望使用SSH和X2go进行远程访问，那么Cockpit提供了一个功能强大的远程管理平台，其中包含越来越多的插件。根据我的经验，一切都很好。
Cockpit的行为符合预期。
我现在要做的就是使用巨型车架换高档。MTU 1500给我带来了大约2-4Gbps的瓶颈，困扰着CPU0。没有人有时间这样做。设置MTU 9000后，突然间，它会同时获得全部10Gbps的带宽和时间，以节省CPU资源。同样，使用硬件辅助的LAG会很好，因为该设备应该能够处理高达150Gbps的双工（不带汗水（带有100Gbe QSFP选件）），考虑到Ubiquiti ES-16-XG最高可达到160Gbps的全双工，这很好（10gb / 16个端口）。
贮存
作为一种存储解决方案，该硬件在较小的散热窗和节省能源的情况下具有很高的价值。我可以用便宜的旧x86盒实现类似的性能，但仅能源使用一项就能在短期内抵消任何节省。相比之下，我已经看到一些消费类NAS设备提供10Gbe和NVMe缓存，共享的PCIe2通道数量不足，并且在总线上出现瓶颈。这是完全可定制的，并且由于能源消耗类似于小型笔记本电脑，小型UPS备份应允许完全写回缓存模式，以实现最佳性能。如果需要，这将成为一个很好的oVirt NFS或iSCSI存储池。我会把它与一个不错的NAS机箱或带托架的机架式机箱配对。正如我们所说，诸如Bamboo之类的一些供应商实际上正在围绕该平台构建服务器选项。
该主板有4个SATA3端口，但是如果我真的要用它构建一个NAS，我可能会添加一个RAID卡，该卡可以充分利用PCIe8x插槽，值得庆幸的是，该插槽是开放式的。为什么有些硬件供应商选择包括封闭式PCIe 8x，4x插槽，这超出了我的范围。未来的型号将配备物理x16插槽，但只有8x电气插槽。SolidRun Discord上的一些用户谈论分叉并拆分8个PCIe通道，这也是一个选择。请注意，其中一些通道还保留用于NVMe，SATA和网络。由于NXP LX2160A文档声称支持多达24条通道，因此CEX7尺寸因子和可互换的载板在稍后提供了有趣的可能性。对于开发板来说，按原样完美就可以了。
网络性能
目前，我已经设法通过NetworkManager组建了一个4×10的LACP团队，以实现全面的负载平衡。可以使用QSFP +分支电缆完成相同的设置。KDE nm网络小部件仍然不支持团队，但是我可以通过nm-connection-editor或Cockpit对其进行设置。可以使用nmcli和teamdctl实现自动化。一项iperf3测试显示，与工作站上2×10 LACP团队之间的连接最大约为13Gbps。我知道iperf并不是真实使用情况的真实指示，但对于基准测试和调整仍然很有趣。实际上，这确实需要进行大量调整，在这一点上，我觉得我可以仅使用iperf统计信息来填充一本书。
$ iperf3 -c honeycomb -P 4 --cport 5000 -R
Connecting to host honeycomb, port 5201
Reverse mode, remote host honeycomb is sending
[ 5] local 192.168.2.10 port 5000 connected to 192.168.2.4 port 5201
[ 7] local 192.168.2.10 port 5001 connected to 192.168.2.4 port 5201
[ 9] local 192.168.2.10 port 5002 connected to 192.168.2.4 port 5201
[ 11] local 192.168.2.10 port 5003 connected to 192.168.2.4 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 1.00-2.00 sec 383 MBytes 3.21 Gbits/sec
[ 7] 1.00-2.00 sec 382 MBytes 3.21 Gbits/sec
[ 9] 1.00-2.00 sec 383 MBytes 3.21 Gbits/sec
[ 11] 1.00-2.00 sec 383 MBytes 3.21 Gbits/sec
[SUM] 1.00-2.00 sec 1.49 GBytes 12.8 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
(TRUNCATED)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ 5] 2.00-3.00 sec 380 MBytes 3.18 Gbits/sec
[ 7] 2.00-3.00 sec 380 MBytes 3.19 Gbits/sec
[ 9] 2.00-3.00 sec 380 MBytes 3.18 Gbits/sec
[ 11] 2.00-3.00 sec 380 MBytes 3.19 Gbits/sec
[SUM] 2.00-3.00 sec 1.48 GBytes 12.7 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 3.67 GBytes 3.16 Gbits/sec 1 sender
[ 5] 0.00-10.00 sec 3.67 GBytes 3.15 Gbits/sec receiver
[ 7] 0.00-10.00 sec 3.68 GBytes 3.16 Gbits/sec 7 sender
[ 7] 0.00-10.00 sec 3.67 GBytes 3.15 Gbits/sec receiver
[ 9] 0.00-10.00 sec 3.68 GBytes 3.16 Gbits/sec 36 sender
[ 9] 0.00-10.00 sec 3.68 GBytes 3.16 Gbits/sec receiver
[ 11] 0.00-10.00 sec 3.69 GBytes 3.17 Gbits/sec 1 sender
[ 11] 0.00-10.00 sec 3.68 GBytes 3.16 Gbits/sec receiver
[SUM] 0.00-10.00 sec 14.7 GBytes 12.6 Gbits/sec 45 sender
[SUM] 0.00-10.00 sec 14.7 GBytes 12.6 Gbits/sec receiver
iperf Done
关于iperf3的注意事项
我之前在同一交换机上使用HP群集完成了LACP Team配置工作了数小时。我曾经听说过有关债券的最新消息，而团队的支持则为单个TCP流增加了更好的负载平衡。这似乎仍然是虚假的，因为根据我的经验，您仍然无法平衡团队的单个流程。LACP还声称它比传统的负载均衡中继线完全自动化并且易于设置，但我发现事实恰恰相反。对于它声称要实现自动化的所有功能，您仍然需要在交换机和主机上正确配置哈希算法。途中有一些怪癖，我曾经不小心将一个团队留在广播模式（不是LACP）下，该团队在iperf服务器上注册了重复的数据包，并使其看起来像单个连接正在获得双倍带宽。
然后，我终于在Ubiquiti的新固件GUI中找到了LACP哈希设置。它隐藏在每个LAG上的小铅笔图标后面。当它们默认为MAC /端口时，我设法将LAG设置为在Src + Dest IP +端口上散列。即使在有并行客户端的情况下，我仍然只看到我的2×10团队的一个奴隶上有流量。最终，我尝试使用-V并行客户端，这一切都说得通。默认情况下，iperf3客户端端口为临时端口，但它们遵循偶数顺序：42174、42176、42178、42180等...如果您在一对顺序MAC上的lb哈希包括src + dst端口，但这些端口始终为偶数，则永远不会用奇数MAC击中另一个接口。iperf这样做有多疯狂？我尝试查看iperf3的源代码，但我什至看不到这是怎么回事。相反，如果您指定客户端端口以及并行客户端，它们使用直接序列：50000、50001、50002、50003等。在客户端端口中使用奇数+偶数，我终于可以跨所有LAG组中的所有接口进行LB。这种设置可以很好地扩展网络上的更多客户端。
正确的LACP负载平衡。
一切都可能会调整得更好一些，但就目前而言，它的性能非常出色，这让我的QNAP感到羞耻。我将继续尝试使用网络协处理器，并查看是否可以启用本机LAG支持以获得更好的性能。在整个网络中，我期望实际峰值大约为40 Gbps，这是巨大的。
虚拟化
那病毒呢？拥有16个A72内核的最好的部分之一是使用KVM全速支持Aarch64 VM，而在x86上则无法做到。我可以使用此单个框一次启动十几个VM，以进行CI自动化和测试，或者仅使用COPR上的aarch64构建来测试我们最新的HashiCorp构建。不带KVM的x86上的Qemu可以模拟aarch64，但通过比较进行爬网。我还没有尝试将其添加到oVirt集群中，但是实际上它确实很灵活，并且比在云中旋转Arm VM更具成本效益。NFV就是这种环境的用例之一，只要您将它与ECC RAM配对即可，它就非常适合它，因为我没有运行任何关键操作，所以我跳过了它。如果有人想测试我的VM DM，我将尽力为您提供一些临时访问权限。
Cockpit中的虚拟机
基准测试
Phoronix已经在OpenBenchmarking.org上做了很多基准测试但是我想使用自己的Fedora 33构建中的最新版本重新运行它们，以保持一致性。我还想将它们与Xeons进行比较，这并不是一个公平的比较。两者都使用具有相似时钟频率的DDR4 –大约2Ghz，但是不同的体系结构和缓存显然会产生不同的结果。Xeons还是双插槽，这对于单线程工作负载而言是巨大的散热优势。您可以看到一个进程在最凉爽的CPU插槽之间反弹。Honeycomb没有这种奢侈，它的风扇较小，但是时钟速度在2Ghz时安全且缓慢，因此我敢打赌，如果调整了散热，SoC会有运行得更快的空间。我也没有使用PWM设置来调节风扇速度，以防万一。使用调整后的配置文件网络吞吐量执行的基准测试。
奇怪的是，某些单核操作实际上在Honeycomb上的性能要比在Xeons上好。我在一些文件上尝试了默认级别3的单线程zstd压缩，发现它实际上在Honeycomb上的性能始终更好。但是，将实际的pts / compress-zstd基准测试与多线程选项一起使用会打开表。16个内核仍然管理着令人印象深刻的2073 MB / s：
Zstd Compression 1.4.5:
pts/compress-zstd-1.2.1 [Compression Level: 3]
Test 1 of 1
Estimated Trial Run Count: 3
Estimated Time To Completion: 9 Minutes [22:41 UTC]
Started Run 1 @ 22:33:02
Started Run 2 @ 22:33:53
Started Run 3 @ 22:34:37
Compression Level: 3:
2079.3
2067.5
2073.9
Average: 2073.57 MB/s对于苹果与橙子的比较，我的2×10核心Xeon E5-2660 v3盒的速度为2790 MB / s，因此2073作为潜在工作站似乎非常受人尊敬。与中型GPU搭配使用，该设备还将成为出色的视频转码器或媒体服务器。一些用户询问了挖矿问题，但我不会使用其中之一来挖矿加密货币。PCIe原子的缺乏意味着可能不支持某些OpenCL和CUDA功能，并且仅暴露8个PCIe通道，您的能力受到很大限制。也就是说，它有可能成为一个出色的移动ML，VR，IoT或视觉开发平台。可能性非常开放，因为整个包装非常平衡且灵活。
结论
今年我的组织能力不足，无法安排FOSDEM的访问，但这是我很想谈论的事情。我很高兴我尝试了。特别感谢Jon Nettleton和SolidRun Discord上的人员提供的帮助和故障排除。该套件功能强大，并有可能替代我家庭实验室中的大量能源浪费。它为开发提供了一个出色的Arm平台，很高兴看到Fedora的替代体系结构支持牢固。那天我在Gentoo上启动了Linux，但是Fedora确实提高了它的原型。我真的很高兴我不必坐在专有平台上等待编译。我期待其余的补丁程序能够成为Fedora内核的主流，并且我希望看到更多的人使用此程序包，尤其是在Apple全面采用Arm的情况下。
