Mikrotik HAP AC2 FastPath FastTrack 性能测试
本帖最后由 rx_78gp02a 于 2024-10-11 13:30 编辑摘要：通过对HAP AC2进行小包测试，探究FastPath、FastTrack之间的差异
贫穷的我买不起什么高端路由，只能对手上的HAP AC2做个简单测试，先放官方数据。Routing（FastPath ）为1488Kpps，Routing（25 IP Filter）为242.9Kpps
Trex UDP单向均能跑满1.47Mpps，和官方数据一致，但是双向必须限制单向发包速率低于750Kpps合计1.47Mpps，否则速率下降只有834Kpps
增加一条NAT规则以关闭FastPath
add action=masquerade chain=srcnat disabled=yes out-interface=ether2
Trex UDP单向145Kpps/150Kpps，双向71.5 Kpps +71.6 Kpps =143Kpps，双向必须限制单向发包速率低于100Kpps合计200Kpps，否则速率下降只有120Kpps
增加FastTrack规则，并打开所谓的“硬件加速”
/ip firewall filter
add action=fasttrack-connection chain=forward connection-state=\
established,related hw-offload=yes
add action=accept chain=forward connection-state=established,related
Trex UDP 单向128.79Mbps / 512Mbps * 1Mpps=251Kpps FastTrack Packets显示为0，表明UDP没有进入加速状态。
更正说明，单向UDP包无法进入FastTrack加速，数据必须通过原端口返回才行。
Trex TCP UDP双向515.9Kpps，FastTrack Packets 有数据，CPU单核满载，总占用73%
更正说明，这里用的UDP发包，为了探究为何UDP无法加速写了几个模板，和/avl/oracle.pcap混淆了，oracle.pcap走的TCP但是速率不够高
关闭所谓的“硬件加速”
/ip firewall filter
add action=fasttrack-connection chain=forward connection-state=\
established,related hw-offload=no
Trex TCPUDP 双向512.8Kpps，FastTrack Packets 有数据，CPU单核满载，总占用67%，你就说这hw-offload有木有卵用？
关闭FastPath/FastTrack，Trex TCP UDP双向254Kpps，CPU单核满载，总占用94%。接近官方Routing（25 IP Filter）
打开FastPath，Trex TCPUDP 双向663Kpps，CPU单核满载，总占用62%。单核满载直接影响TCP性能，FastPath对TCP收益不远比不上UDP。
建立一条simple queue规则，自动关闭FastPath/FastTrack
/queue simple
add disabled=yes dst=ether2 max-limit=1G/1G name=queue1 target=""
Trex TCPUDP 双向217Kpps，CPU单核满载，总占用90%。
Trex TCPUDP 双向233Kpps，CPU满载导致WINBOX退出。
附带一张UDP可进入FastTrack加速的测试结果
关于发包速率过快导致转发降速问题，包进入路由产生中断消耗大量CPU资源，从端口状态看到RX明显比TX高，因为RouterBoard没有RPS功能，核心提前满载导致发包速率降低。
UDP小包可测出官方性能，但CPU最高只用到两个核心。
一条simple queue即可把性能打回内核转发，尝试很多方法，无法得到官方25 simple queue的数据。官方亦未公布配置说明。simple queue + FastTrack可以得到500Kpps左右的转发速率，但是进入simple queue的包很少，官方测试作弊？
任何方式进行UDP测试均无法获得FastTrack加速，尝试单独设置一条规则单独指向UDP：
/ip firewall filter
add action=fasttrack-connection chain=forward connection-state="" hw-offload=\
yes protocol=udp
add action=accept chain=forward connection-state=established,related
测试时有数据记录，但是ip settings的fasttrack packets无新增，证明实际未被加速。
更正：单向UDP流无法进入FastTrack加速，能加速的是reply流
总结：
RouterBoard吃单核性能，负荷无法均分。
因为吃单核，FastPath对TCP收益不高。
FastTrack性能远比不上官方标注的FastPath（UDP）指标，并且无参考依据。
FastTrack 对UDP加速无效，至少大部分情况下应该是无效的，模拟过DNS请求，也无效。
FastTrack 对hw-offload=yes 设置无效。
无法获取官方25 simple queue的性能指标，多种模板均无法实现接近的结果。
本质上ros就是linux 5.6的魔改版，又怎会有质的变化。 所以早早换x86了，RouterBoard性能太垃圾了，超频都没用 summerq 发表于 2024-10-10 21:32
本质上ros就是linux 5.6的魔改版，又怎会有质的变化。
我只是好奇它的FastTrack能有多大加成，初步看比内核转发快一倍，匪夷所思的是udp居然一个包也加速不了 测这些数据也是辛苦。 本帖最后由 525165 于 2024-10-11 01:44 编辑
不太理解这种测试的意义
具体参数官网已经给出（堪称业界标杆），是专业测试仪器按照标准测试流程测出的结果，而不是开源打流软件和臆想的测试方法
FT与FP的介绍有详细的文档
另外FT，FP也和硬件加速没一点关系
Router OS各个设置耦合性非常大
如果要拿出有说服力的数据
请在每个测试项目前贴上完整的配置
避免设置错误导致结果错误 525165 发表于 2024-10-11 01:22
不太理解这种测试的意义
具体参数官网已经给出（堪称业界标杆），是专业测试仪器按照标准测试流程测出的结 ...
隔壁讨论CPU如火如荼，不说真假，但至少是放了不少测试数据，同时也有人打算入手自测以证虚伪。
再看看你：就只有嘴硬了
https://forum.mikrotik.com/viewtopic.php?t=184890
https://forum.mikrotik.com/viewtopic.php?p=1088426&hilit
UDP和ipv6连软件加速都没吧，还有祖传的单核瓶颈[流汗] rx_78gp02a 发表于 2024-10-11 09:58
隔壁讨论CPU如火如荼，不说真假，但至少是放了不少测试数据，同时也有人打算入手自测以证虚伪。
再看看你 ...
有什么问题么？
5009有硬件加速有问题么？
硬件加速和FT，FP有关系么？
你发的这些测试结果想要证明什么？有意义么？ 本帖最后由 rx_78gp02a 于 2024-10-11 19:17 编辑
525165 发表于 2024-10-11 17:08
有什么问题么？
5009有硬件加速有问题么？
硬件加速和FT，FP有关系么？
引用你说的话
"我个人的观点RB5009属于硬路由，依据是"小包转发率"这一指标"
"rb5009以更低的功耗实现了包转发速率的大幅领先，这正好是硬件加速的目的和效果"
"硬件加速和FT，FP有关系么？"
"另外FT，FP也和硬件加速没一点关系"
一边根据Mikrotik官方FastPath的测试结果臆想RB5009有硬件加速
反口又说硬件加速和FastPath/FastTrack无关
那么我们来看非FastPath的测试结果，是1.095Mpps还是761Kpps让你觉得 "实现了包转发速率的大幅领先" ？？？
引用你说的话
"你发的这些测试结果想要证明什么？有意义么？"
全网都找不到FastTrack的性能数据，这个测试不敢说开天辟地，至少是填补空白。
数据证明，你们能用到的FastTrack性能不过如此，就别臆想它是硬路由。
MT7988 双流双向29.82Mpps，IPQ8074 2000流双向14.5Mpps，CPU零占用，这才叫硬路由！
引用你说的话
"通用X86处理器软路由，在小包转发率这一指标上大幅落后"
确实69.8Mpps的软路由小包转发率大幅落后
525165 发表于 2024-10-11 17:08
有什么问题么？
5009有硬件加速有问题么？
硬件加速和FT，FP有关系么？
请你来个“科学”的测试呗 lz居然还有精力跟杠精吵… 他那几个帖子直接就暴露自己是ETC转世了，主打一个不听不看，自动抬杠。
看的，我也来上个数据。RB450GX4，V7.16。
/ip firewall filter
add action=fasttrack-connection chain=forward connection-state=established,related hw-offload=yes
add action=accept chain=forward connection-state=established,related
/system routerboard settings
set cpu-frequency=896MHz 本帖最后由 525165 于 2024-10-11 21:44 编辑
rx_78gp02a 发表于 2024-10-11 19:08
引用你说的话
"我个人的观点RB5009属于硬路由，依据是"小包转发率"这一指标"
说个结论：你真的不懂，只会瞎扯，只会自己感动自己的表演
建议补补课再来
否则发再多贴做再多臆想测试，只会浪费时间 本帖最后由 525165 于 2024-10-11 21:39 编辑
summerq 发表于 2024-10-11 19:15
请你来个“科学”的测试呗
如果你想知道测试方法，可以告诉你
如果你想知道测试结果，官网已经给出
我个人没有测试设备，也不会装个开源软件做些毫无意义的臆想测试，更不会不懂装懂的东拉西扯 525165 发表于 2024-10-11 21:38
如果你想知道测试方法，可以告诉你
如果你想知道测试结果，官网已经给出
我个人没有测试设备，也不会装个 ...
嗯 我就想知道你的测试方法。结论没关系 summerq 发表于 2024-10-11 21:43
嗯 我就想知道你的测试方法。结论没关系
525165 发表于 2024-10-11 17:08
有什么问题么？
5009有硬件加速有问题么？
硬件加速和FT，FP有关系么？
上次那个帖子消失了？不是已经讨论验证了好几轮5009是纯软路由了么，只有软件offlod[流汗] blanksign 发表于 2024-10-11 21:32
看的，我也来上个数据。RB450GX4，V7.16。
/ip firewall filter
add action=fasttrack-connection chain=f ...
图糊了，但是注意queue tree 的avg rate 没开fasttrack的时候显示的mbps，开了之后显示的kbps，表明大量包并没有进入queue tree。cpu占用的差异是由队列所致。我有测试过simple queue和fasttrack同时使能，simple queue有数据，但是和实际包数不符，也能跑到较高转发率，但这是牺牲功能提升转发。 本帖最后由 blanksign 于 2024-10-11 22:21 编辑
rx_78gp02a 发表于 2024-10-11 22:13
图糊了，但是注意queue tree 的avg rate 没开fasttrack的时候显示的mbps，开了之后显示的kbps，表明大量 ...
糊了也没辙。1080P直接截图。我纯属凑个热闹。RB450GX4，还是要fasttrack。不然都跑不满带宽。迅雷下载的游戏包130GB。 本帖最后由 summerq 于 2024-10-12 02:46 编辑
525165 发表于 2024-10-11 21:47
官方测试结果我看了 应该是udp单向测试的结果。楼主还测试了双向，发现性能有下降很多，这并不跟官方测试矛盾。之后楼主也测试了tcp，因为tcp包还包括包头信息，因此性能下降也属于正常。整体看结论，我并不能得出trex很山寨，或者说十分不靠谱的结论。同时，我可以确定，官方是没有发布双向测试的结果的，而这点被楼主发现了，这是好事。其实楼主最近发的一系列帖子，是在寻找硬件转发的限制，同时说明软件dpdk+vpp的方案没有这些限制，这一点在我看来确实是正确的。这也是为什么我说具体测试的结果，数字不重要，而理解数字背后之含义，反而是有意思的事情。
补充一下，软路由目前除了功耗较高之外，确实性能上在10-100g这个范围，是要比miktrok硬路由好的（但这并不意味着所有硬路由都不好。huawei，cisco或者arista的方案肯定是可以线速的）不管是并发小包，还是快速链接增加都是如此。而在100-800g这个领域，还是asic交换芯片具有绝对的统治地位。
论坛存在的意义，也并非谁要说服谁，或者证明谁比谁更愚蠢。而是通过坛友之间的交流，学习到了新的知识，或者获得了新的经验。别人花了几十上百小时的经验，我们几秒钟就获得了，这里面的价值，不是很巨大吗 2021年我就发现用于拨号的hap ac2在开启IPv6时，难以跑满千兆下行（CPU单核满载），那时就换成用B610-4E光猫拨号了 本帖最后由 mustleave 于 2024-10-12 07:50 编辑
给lz的求真精神点赞 支持，很专业的测试，得慢慢学习跟上 本帖最后由 525165 于 2024-10-12 10:15 编辑
summerq 发表于 2024-10-12 02:41
官方测试结果我看了 应该是udp单向测试的结果。楼主还测试了双向，发现性能有下降很多，这并不跟官方测试 ...
简单表达几点：
1，如果做到硬件转发，UDP和TCP是不会有区别的
2，基于基本的实现原理和结构差异，软路由至少在三个指标（功耗，小包转发能力，数据包转发延迟）是永远无法与硬路由抗衡的（软：指的是“软件路由器”，无额外加速硬件辅助和加速硬核。硬：指的是有硬件转发能力并正确开启的路由器）
3，有些soc，可能做不到数据包从入到出的全流程硬件加速，只是做了部分步骤的加速，对比软路由也会有明显优势
另外我所有发的技术相关帖，初衷只是做技术讨论，这也是让坛友摆数据摆依据的原因（只不过是林子太大了）
有讨论才有进步，互相学习，人外有人，天外有天 525165 发表于 2024-10-11 21:36
说个结论：你真的不懂，只会瞎扯，只会自己感动自己的表演
建议补补课再来
你没正面回答我的问题，是哪个指标让你觉得RB5009“包转发速率的大幅领先”？
你说的最多的几句：
“说个结论”
“你不懂”
“浪费时间”
“毫无意义”
“？”
只会把网络上找到的一些名词拼凑在一起，除此之外，连最简单的一个RB5009 “以更低的功耗”这个指标都证明不了。 525165 发表于 2024-10-12 10:11
简单表达几点：
1，如果做到硬件转发，UDP和TCP是不会有区别的
“另外我所有发的技术相关帖，初衷只是做技术讨论，这也是让坛友摆数据摆依据的原因（只不过是林子太大了）”
引用你说的话
"我个人的观点RB5009属于硬路由，依据是"小包转发率"这一指标"
"硬件加速和FT，FP有关系么？"
"另外FT，FP也和硬件加速没一点关系"
所以，你的依据是什么？
"rb5009以更低的功耗实现了包转发速率的大幅领先，这正好是硬件加速的目的和效果"
所以，你的依据又是什么？
除了嘴炮和嘴硬之外，毫无依据，连“功耗”这个最容易获取的数据都没有。
本帖最后由 525165 于 2024-10-12 10:40 编辑
rx_78gp02a 发表于 2024-10-12 10:27
你没正面回答我的问题，是哪个指标让你觉得RB5009“包转发速率的大幅领先”？
你说的最多的几句：
“说个 ...
你的不懂是多方面的，不是一个点
很多结论都是错误的，然后依据错误的结论臆想出了更多错误的结论
具体也不想多说了，否则会无休止 microka 发表于 2024-10-12 04:23
2021年我就发现用于拨号的hap ac2在开启IPv6时，难以跑满千兆下行（CPU单核满载），那时就换成用B610-4E光 ...
请问，B610-4E光猫拨号后光猫 ipv6是怎么设置的，内网设备如何处理 v4/v6 dns 解析？ 硬的软的我都搞过，我也来凑个热闹呗
1.硬路由，华为AR2220E-S，升级到最新版本
2.软路由，志强E5-2680 v4+32G内存+华为SP330（X710-DA2）网卡，一块I350电口，装IK os
3.我用到的功能不多，就只做拨号+NAT，端口映射，策略路由，多拨，有的还要做一些行为管理功能
4.功耗方面AR2220E-S运行功耗30w左右，软路由大概是在50-80W左右
5.从我个人以往的组网经验来看，组网规模从100-1000个终端左右网络规模，硬路由组网选型合适，在网络使用体验上，我不说是软路由，对比并无差异，稳定性也不用过多担心软路由不稳定，照样开机100多天，不停电，一样稳定
对于我来说软和硬，各有各的优势，硬路由，软件成熟，功耗低，功能稳定，缺点就是升级扩展性不高，并且华为AR2220E-S板卡也不便宜，软路由嘛，就比较灵活了，只要固件软件驱动支持，可以灵活更换网卡，软路由的一些功能上也比硬路由要灵活，组网规模比较大的环境，我个人更偏向用软路由当作出口路由来组网，性能不够，硬件来凑，系统固件挂了，重刷就得了（时至今日，并没有遇到过），要是硬路由遇到固件挂了，就直接变砖了