RouterOS 队列里累计了约 264 万包 dropped，NAS 的 bridge0 接收丢弃也在缓慢增加。这次两处都查了：宽带这边做双向满载测试，NAS 那边抓包核对来源。
数据来自 2026 年 10 月 15–16 日，满载测试在 15 日完成。
10 月 21 日只读复核，队列仍为下行308 / 上行116 Mbps，使用中的FQ-CoDel target为6ms，bucket-size为0.05。下面的吞吐、Ping与丢弃增量保留原测试日期，没有重新跑满载；NAS的RLDP判断也沿用当时的抓包证据。
308/116 Mbps 下的满载测试
最后保留的限速是 下行 308 Mbps、上行 116 Mbps。高、中、低类用 FQ-CoDel，Other 类用 PCQ。10月15日调QoS时没有改流量分类；16日对分类同步脚本和设备地址记录的维护另见第四篇。
两轮测试都同时跑上下行，每轮约 36 秒：
| 指标 | 第一轮 | 第二轮 |
|---|---|---|
| 路由器稳定段下行 / 上行（Mbps） | 303.35 / 111.35 | 302.81 / 111.77 |
| IPv4 Ping 平均值（ms） | 5.922 | 5.934 |
| IPv6 Ping 平均值（ms） | 6.392 | 6.491 |
| 下行队列丢弃估算 | 3.457% | 1.293% |
| 上行队列丢弃估算 | 0.186% | 0.181% |
两轮合计，IPv4 和 IPv6 各收到 180/180 个 Ping 回复，物理 WAN 接口没有新增错误或丢弃。平均 Ping 约 6 ms，第二轮 IPv4 最大值是 18.289 ms。
吞吐取的是路由器稳定采样段。客户端把开始爬升也算进去，全程平均约下行 266 Mbps、上行 101 Mbps，和表里的采样窗口不同。第一轮 PPPoE 计数还发生过异步重置，队列丢弃比例采用重置后的绝对数计算，所以标成估算。
FQ-CoDel 的 target 当时设为 6 ms，管的是持续排队延迟，并不限制整条链路的 Ping 上限。bucket-size 0.05 对应约 50 ms 的限速流量额度，实际突发多久还取决于流量。参数说明在 RouterOS 队列文档里。
264 万是累计数，没有清零
当时队列累计的约264万包没有为这次测试清零。它是10月15日看到的历史计数，不是现在仍应读到的固定值；累计数没有对应的起止窗口，没法直接拿来算这次满载测试的丢包率。
队列丢弃发生在限速和排队处，主动队列管理（AQM）会用丢弃反馈拥塞；物理网口的错误和丢弃要看网卡、链路；Ping 则只记录那次探测有没有收到回复。当时队列仍有丢弃，选定目标的 Ping 全部回复，WAN 计数没有增长，这几项都按原样留了下来。两轮短时 Ping 没有覆盖所有应用和长期使用。
10 月 16 日改完 DNS、防火墙和脚本后，又看了几个普通业务窗口，没有重做双向满载。其中一段 Other 上传队列新增 8 包丢弃，最后一段则有流量、没有新增队列丢弃。
NAS 上增长的 11 次接收丢弃
NAS 的 bridge0 在慢慢增加接收丢弃，物理网卡和软中断计数却没有同步增长。
先查的是 WAN 交换机。它的环路检测关闭，管理 MAC 也和抓到的发帧源不同。后来补查 LAN 交换机，发帧源才和它的管理 MAC 对上：LAN 侧能抓到定时的 RLDP 环路探测帧，WAN 侧没有相同样本。
约 30.2 秒内，NAS 收到 11 帧，桥接口的接收丢弃正好增加 11。内核接收路径显示，这批帧因为本机没有处理对应协议而被忽略。Linux 的接收丢弃计数包含不支持协议等情况，见内核接口统计说明。对上的是这一小段增长，历史丢弃没有逐一追溯。
这次没有关闭 LAN 交换机的环路检测，也没改 NAS 网卡设置，原始计数继续保留。前后检查的 SMB、NFS 和选定管理端口都可达。