|
|
本帖最后由 rx_78gp02a 于 2024-10-11 13:30 编辑
摘要：通过对HAP AC2进行小包测试，探究FastPath、FastTrack之间的差异
贫穷的我买不起什么高端路由，只能对手上的HAP AC2做个简单测试，先放官方数据。Routing（FastPath ）为1488Kpps，Routing（25 IP Filter）为242.9Kpps
01
Trex UDP单向均能跑满1.47Mpps，和官方数据一致，但是双向必须限制单向发包速率低于750Kpps合计1.47Mpps，否则速率下降只有834Kpps
02
03
04
增加一条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
05
06
07
增加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加速，数据必须通过原端口返回才行。
08
Trex TCP UDP双向515.9Kpps，FastTrack Packets 有数据，CPU单核满载，总占用73%
更正说明，这里用的UDP发包，为了探究为何UDP无法加速写了几个模板，和/avl/oracle.pcap混淆了，oracle.pcap走的TCP但是速率不够高
09
关闭所谓的“硬件加速”
/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有木有卵用？
10
关闭FastPath/FastTrack，Trex TCP UDP双向254Kpps，CPU单核满载，总占用94%。接近官方Routing（25 IP Filter）
11
打开FastPath，Trex TCPUDP 双向663Kpps，CPU单核满载，总占用62%。单核满载直接影响TCP性能，FastPath对TCP收益不远比不上UDP。
12
建立一条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退出。
13
14
附带一张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的性能指标，多种模板均无法实现接近的结果。
|
|
310112100042806
发表于 2024-10-10 20:59
