@yanpj1992 驱动确认装了，meson 的时候看到 mlx5 已经 enabled 了

应用层的比网络层的优先，系统代理始终会更早一步。

举几个例子，如果你开了系统代理，代理服务器 IP 是你的 VPN 内网里的某个 IP ，用到代理的时候，浏览器会发起代理连接，这个连接的数据包会路由到你的 VPN 里，最后发到你内网里处理，这个过程里它先走了系统代理然后会走路由甚至还走了你 VPN 的路由。如果你浏览器打开你 VPN 内网的 IP ，这个 IP 如果不在浏览器设置的代理排除列表，就会走代理服务器，如果刚好你的代理服务器是本地（ 127.0.0.1 ）的 xxx 软件，刚好你本地的代理服务器代理发起连接时认为这不是个需要加速的 IP ，它代理出来的流量仍然会走你的 VPN （因为它发起了连接 IP 是你内网的 IP ，就路由到你的 VPN 虚拟网卡了），你就可以访问内网成功，但是如果被认为是个需要加速的 IP ，就加密发到 xxx 软件的服务器去了，最后你这个访问内网就不通了。

详细的说，这两个概念不同。系统代理是个应用层的玩意，就一个实现 SOCK5 、HTTP 之类的前置代理协议的服务而已，VPN 用的那个路由表是个网络层（ L3 ）的概念，两个东西不一样。

[系统代理] 需要你的浏览器等软件支持代理协议，你才可以走这个代理。在你浏览器配置了系统代理时，会填写一个代理服务器地址（例如 127.0.0.1:1080 ，或者 PAC 文件，但是最后还是解析出代理服务器地址）。当你打开网页的时候，浏览器就会连接这个代理服务器，传输代理协议头和你网页的请求，这个连接过程就会创建一个 TCP 连接，会查路由表发到代理服务器（如果代理服务器是 127.0.0.1 ，就路由到本地，如果是外部 IP ，就路由出去），代理服务器收到之后再自己再代理请求。

[VPN] VPN 客户端在你系统上路由表上安装了控制端下发的几条路由，把你的 IP 数据包直接路由到它的虚拟网卡里，软件中能接到虚拟网卡来的包，软件处理把你的 IP 数据包打封装发到 VPN 服务器，然后 VPN 服务器解封装，就在它的网络里发走了。

@Dzsss 主要是没有相似场景参考单流实际转发速度能到多少，想保底选 VPP 的方案，但是 DPDK 测 Mellanox CX5 网卡的时候一直有问题，不想折腾了。想问问大佬，你那个配置，RB5009 单流（就是单核处理，不是多流同时的总和速度）能到 1Gbps 吗？能到我就冲了，不纠结了

以及这里补充一下，手边正好有一台 i226 网卡的工控，装完 CHR v7 版本的，开机直接内核 fault ，console 只打出来了最后十几行，看不到前边的 stack trace 信息，暂时也不知道是哪里的问题，看起来 x86 装 ROS 这条路确实不太好走，兼容性和稳定性不太好确定。

@FlintyLemming 了解，多谢大佬

@kenneth104 我这里 BGP 条目很少，也就几百条，ROS 的 BGP 我之前参加 MUM 的时候有人说了，就是前缀多的时候接起来特别慢。

x86 确实容易超过 5009 ，我找了 fd.io VPP 的 performance tuning ，发现 x520 的网卡+1 个 cpu 核心，三层转发就可以到 10Mpps 以上，四层 abr 也能有 6Mpps 多，确实直接秒 5009 。手边正好有几台空的机架服务器和几张 mellanox 、intel 的网卡，在考虑要不要自己做网关了。

@Ipsum 大概跑到多少速度来的？以及有 pps 参考不

@dann73580 是，我看到有人说 ROS 的 i226 拉不满，但是 Linux 发行版系统就可以，可能还是有一些问题。

@Dzsss 我不开 fast track 是因为，做 pbr 之后并且还要再迂回（在 pbr 网关做了一次 masquerade 的）到同一台 ROS v7 机器后，pbr 会有问题（忘了之前测的是不通还是失效了），但是 ROS v6 的没有这个问题，无非是 rp_filter 改到 loose 就行。不过多谢大佬，原来这玩意坑还有这么多，后边我也避免这样用。

这玩意保值是保值，但是下架的机器有人收吗（笑哭

另外想问问大佬，你这 5009 跑这么多东西，规则全开的情况下，单流极限（也就是不 offloading ，靠 CPU 软转单核）能有多少来的？

@jmxct520 贵啊

@yyzh 他这个应该用 dpdk+vpp 做，pbr 这个确实不好 offloading 。不过我今天看到 architechs 的一个 presentation ，x86 的 8 核 RouterOS CHR 也就跑到了 900 多 kpps ，CCR 硬件可以直接 3Mpps ，差远了

1 楼和 2 楼的结果，看起来统计确实不准。。。不知道是苹果的 bug 还是啥，数值能差这么多。。。

@moyaya 多谢，下了一个看了一下，mac mini 实际存储使用量 237G 。

很久之前买过一个小米的，github 有刷机教程，印象里记得要焊 ttl 线，然后进去刷固件，就可以打开外录功能，之前把它接到了群晖的监控上，能用。如果楼主喜欢折腾，可以考虑考虑

多谢大家的回复。我的诉求就一个，能 100%稳定撑够 1 年，等到第二年春节我回来换，所以基本坚持一年的办法就不考虑。本身是做软件的哈哈这些坑真不知道了，经验不多，看了 datasheet 是 LDO 我以为 LDO 都是低功耗的，看来对于 iot 硬件来说这个低功耗还是不够低，既然能直接两串两并 3V ，放电截止电压 1.8V 左右也够用，我试试直接两串两并好了。

没想到晚上来看竟然这么多大佬回复，多谢各位。

评论中蛮多说没搞明白原子性什么意思，我没表达清，其实就是想说单纯说 mysql 的事务 2333 ，还没有用到 redis ，单纯希望在围绕 mysql 的业务流中，业务流和你使用的 atomic 包一样都是原子的不可再切分的。

另外多谢 @BeautifulSoap @heww @thevita @qloog @lxdlam @EchoGroot @nobject 的详细解释，看起来确实还是放在 ctx 里主流一些，容我研究研究。

对比测试了一下，AirDrop 始终开启，频点 36 频宽 160MHz 时，ping 会看到明显的周期性高延迟，从 mac 上复制一个图片，手机端打开淘宝之类触发 airdrop 传输时，立即断网一秒，随后还会持续高延迟几秒，非常明显。频点改为 149 频宽 80MHz 时，ping 非常稳定，不论怎么复制图片触发 airdrop ，延迟没有明显变化，非常稳定。

所以最后找到了确定的解决办法，路由器 Wi-Fi 5g 频点改 149 ，如果你是公司网，建议用有线（但是实际上我觉得高延迟的那一下，如果你不是打游戏其实也还好）。

@HarrisIce 补充一下，重启之后延迟不是非常明显了，改善了 60%，但是还有一点延迟感不是特别影响游戏外的应用，剩下的这问题待我后续改 wifi 频点再试试

@ViolaH 多谢大佬，我看了一下这个文章，看起来本质上还是 airdrop 的问题。自己机器上把 awdl 干掉可以解决，或者就把 wifi 改成 149 频段避免 airdrop 周期扫描时切频点导致的突然高延迟。我的 ap 用的是 160Mhz 所以用的是 36 频点，等我晚上回去试试改 149 看看有没有完全解决