实习周报（2026-07-25）

本周工作进展

本周工作重心从 QEMU 虚拟化环境的网络栈分析转向 SG2002（LicheeRV Nano）真实硬件的 WiFi 性能工程。在上周完成 /proc/net/dev 基础统计框架后，本周将其语义与 Linux 对齐并完成收尾；同时完成了 SG2002 WiFi 驱动修复、板端测试路径搭建和 eBPF 驱动延迟监测工具三个层面的工作，为后续基于实测数据的 WiFi 性能优化建立了基础设施。

一、/proc/net/dev 全部字段统计与 Linux 语义对齐

#1645

上周 #1571 在 ax-net 中铺设了 /proc/net/dev 的基础 L2 帧统计——rx_bytes、rx_packets、tx_bytes、tx_packets 四个计数器。本周的工作在此基础上补齐了 /proc/net/dev 的全部剩余字段，使输出对齐 Linux dev_seq_printf_stats() 的完整 17 列格式（face + rx/tx 各 8 列）。具体包括：

软件可追踪字段（errors、dropped）。这是本周的核心增量——新增 rx_errors、rx_dropped、tx_errors、tx_dropped 四个 AtomicU64 计数器，并在网络栈的关键决策点设置触发路径：

• rx_errors：ARP 畸形包、Ethernet 设备 send_to 返回错误、驱动层 deferred RX error 队列排出
• rx_dropped：Router RX 队列满（RX_QUEUE_SIZE=256 耗尽）、buffer 分配失败、loopback 注入到 RX 队列失败
• tx_errors：路由查找无匹配（含 loopback 回退路径）、request_arp 全部重试失败
• tx_dropped：设备 TX 队列满、MTU 超限拒绝

与 Linux 语义进行了比对，确保每个计数器的语义与 Linux 对应字段一致。

硬件相关字段（fifo、frame、compressed、multicast、colls、carrier）。这 8 个字段在 Linux 中由 NIC 硬件计数器报告（如 FIFO overrun、帧对齐错误、冲突计数等），QEMU virtio 设备没有对应的硬件事件源，因此统一置 0 保留列位。

计数器采集效率优化。在 device_rx_worker 中新增 drain_device_error_counters() 辅助函数，将四路 error/drop drain 合并为一次批量操作，内部使用 AtomicU64::fetch_add 的批量语义替代逐个 load+store。同时将 TX 方向的 deferred counter drain 从 RX worker 中解耦移入 device_tx_worker，消除了两个 worker 之间的不必要耦合——原先 TX 方向的错误计数器要等到 RX worker 下一次被调度才能被冲刷到 DeviceHandle，导致 /proc/net/dev 读取存在观测延迟。

Linux 语义对齐。修正了一个关键偏差：原实现将"无路由匹配"路径的丢包计入 per-interface tx_dropped，而 Linux 对此场景使用全局 IP 层统计 IPSTATS_MIB_OUTNOROUTES（体现在 /proc/net/snmp 的 OutNoRoutes），不体现在 /proc/net/dev 的 per-device 列中。该修正避免了跨内核对比时 /proc/net/dev diff 中的虚假差异。同时为回环接口的计数不对称性（RX 无条件计数、TX 仅成功后计数）补充了与 Linux loopback 驱动行为一致的注释说明。

配套完善。修复了 /proc/net/snmp 中 TCP 段字段数不匹配问题（16→15，对齐 Linux snmp4_tcp_list），为 Udp 段补充了 MemErrors 字段（8→9）。新增 3 个回归测试：/proc/net/dev 17 列结构格式测试、/proc/net/snmp TCP/UDP 字段数匹配测试、无路由不污染 per-device tx_dropped 的行为测试。累计测试通过数从上周的 68 增至 72 个。

至此，/proc/net/dev 的 17 列全部字段均已实现并与 Linux 语义对齐，/proc/net/snmp 的 TCP/UDP/Raw 四协议段也已具备数据填充能力。

二、SG2002 WiFi 驱动修复

上周 SG2002 小车到货后，首要任务是让 StarryOS 在真实硬件上通过 WiFi 接入网络。上电验证过程中发现 AIC8800DC WiFi 驱动在启动阶段失败，表现为固件加载后 RX 线程初始化异常。

经在驱动中打点排查，定位到 components/aic8800/src/fdrv/thread/rx.rs 中 RX 处理逻辑的边界条件处理不当：在固件尚未完成初始化时，RX 描述符环可能返回空或无效帧，原代码对此路径的防御不足，导致线程 panic。修复在 RX loop 的帧检查处增加了状态校验，确保固件就绪后才进入正常收包流程。

该修复（fix&test(sg2002,wifi): fix wifi boot & include sg2002 wifi config）已通过实机验证。未推送。

三、SG2002 真实硬件 WiFi 吞吐测试

WiFi 驱动修复后，本周的核心任务是建立板端测试路径，使 net-bench 测试框架能在真实硬件上运行。与 QEMU 环境不同，板端测试面临资源受限（256MB RAM）、工具链不完整（dropbear SSH、busybox 环境）和网络拓扑不对称（板端开 AP）等约束，需要在测试架构上做出适配。

C/S 翻转架构

QEMU 模式下 net-bench 的拓扑是 Host（iperf3 server）← Guest（iperf3 client），但板端场景恰好相反：板端开 WiFi AP（IP 固定 192.168.50.1），PC 作为 station 连接。因此采用了板端 = iperf3 server、PC = iperf3 client 的翻转架构，这与 QEMU 模型方向相反但更贴合板端的实际网络角色。

翻转后，/proc/net/dev 快照采集在板端侧、iperf3 吞吐数据在 PC 侧，需要精确同步。方案利用 iperf3 -s -1（单次服务，接受一个 client 后自动退出）的语义，将进程生命周期作为天然同步信号：板端脚本在 iperf3 -s -1 调用前后分别采集 /proc/net/dev 快照，PC controller 通过 SERVER_READY 哨兵行轮询确认 server 就绪后启动 client。

SSH 主控方案与问题排查

PC 端通过 paramiko SSH 控制板端，由 board-controller.py 完成测试编排：部署 board-server.sh 到板端、按测试矩阵逐项启动板端 server、采集 L2 快照并汇总。实现中遇到了几个嵌入式 SSH 环境的典型问题：

PTY 阻塞问题（最关键）。iperf3 server 在无 PTY 的 SSH channel 中启动后 hang——iperf3 -s -1 仅输出分隔线，从不打印 Server listening on 且 TCP listener 未创建。经过排除 DNS 解析、IPv6、端口冲突和残留进程等可能性后，发现 channel.get_pty() 分配伪终端后 iperf3 立即正常工作。根因是 iperf3 前台模式在启动时调用 isatty() 或 termios ioctl，在无 PTY 的 channel 中阻塞。OpenSSH 的交互式 session 默认分配 PTY，而 paramiko 的 exec_command() 不分配，这是自动化测试中容易忽略的差异。

dropbear 限制。板端 dropbear 不支持 SFTP 子系统（open_sftp() 抛出 EOF），文件部署改用 exec_command('cat > PATH') + stdin.write() 实现。此外，dropbear host key 和 root 密码需在每次刷机后手动配置，增加了测试准备步骤。

iperf3 UDP server 创建失败。PTY 修复后 TCP 测试正常（单流 uplink 9.93 Mbps，4 流 9.48 Mbps），但 UDP 测试失败——iperf3 UDP server 报 Address in use。交叉验证矩阵显示，当 TCP 和 UDP 两个 socket 均设置 SO_REUSEADDR 并绑定同一端口时，StarryOS 拒绝第二个 bind。该问题的根因定位和修复将在后续进行。

测试结果

板端 TCP uplink（PC→板）吞吐稳定在 ~10 Mbps，板端 L2 统计与 iperf3 应用层数据一致。AP→station 方向（板→PC，iperf3 -R）吞吐仅 0.1 Mbps，L2 统计显示板端确实发送了数据（wlan0 TX 增量 ~1.6 MB），但应用层几乎收不到，符合 WiFi 驱动优化前的表现。

四、网络栈 eBPF 延迟探针

上周确定了 eBPF 在延迟细粒度 trace 场景中的定位——/proc/net/dev 只能给出聚合计数，无法提供单包级别的延迟分布。本周基于这个定位，参考了 netstacklat 工具的设计思路，完成了针对 SG2002 WiFi 驱动的 eBPF 延迟监测工具 wifi_monitor。

实现上采用静态 tracepoint + raw_tracepoint 的组合方案：

Tracepoint 定义（os/StarryOS/kernel/src/tracepoint/wifi.rs）：在 SDIO 传输和 WiFi 帧处理的热路径上设置了六个 tracepoint——wifi:sdio_xfer_start/done（SDIO CMD53 传输延迟）、wifi:tx_frame/rx_frame（帧收发计数和尺寸）、wifi:tx_batch/poll_cycle（批量发送和轮询周期诊断）。驱动组件通过 SdioTrace/WifiTrace trait 调用，默认实现为 no-op，仅在启用 tracepoint feature 时展开为实际记录。

eBPF 程序（apps/starry/ebpf/wifi_monitor/）：使用 aya 框架，eBPF 程序通过 raw_tracepoint 挂载到上述 tracepoint，在 BPF map 中维护 exp2 延迟直方图和帧计数器。用户态 loader 周期性读取并输出，不需要额外的后处理工具链。

内核桥接：tracepoint 的 #[no_mangle] extern "C" 包装函数确保跨 Rust 模块的可靠链接，避免编译器内联或符号重整导致的 tracepoint 失效——这个问题在上周的 eBPF net_stats 探索中已经充分暴露。

该工具的定位是 WiFi 驱动优化的辅助诊断手段：SDHCI 等待延迟反映 PIO 模式的寄存器轮询开销，TX/RX 帧计数和尺寸分布反映聚合效率，批量发送/轮询周期反映调度策略的合理性。与 /proc/net/dev 的聚合统计形成互补——前者回答"卡在哪里、卡了多久"，后者回答"丢了多少、效率如何"。

五、其他

上周列出的 net-bench 应用层统计闭环和 /proc/net/snmp 数据填充工作，因本周重心调整为 SG2002 WiFi 实机测试，暂时纳为 todo。上周末的 SG2002 WiFi 吞吐差距分析（PHY 速率差 ~60%、SDHCI PIO vs DMA ~30%、聚合深度 ~10%）为本周的工作优先级排序提供了依据——在驱动修复和测试路径搭建这两个更基础的问题解决之前，上层协议栈的统计细化需要让位。

下周工作计划

一、完善并集成测试流程

本周的板端测试路径已能跑通 TCP 吞吐测试，但离 CI 可用的自动化程度还有距离。下周将在以下方向完善：

• UDP 测试恢复：排查 StarryOS SO_REUSEADDR 跨协议绑定的根因并修复，恢复 UDP 吞吐和丢包率测试
• 自动化部署：将 board-server.sh 预置到 rootfs、dropbear host key 预生成、WiFi AP 自动配置，减少每次测试的手动准备步骤
• 反向测试支持：评估 --net=host 模式或 socat 中继方案，解决 Docker NAT 对 AP→station 方向（tcp1r）测试的限制
• 测试矩阵扩展：在现有 tcp1/tcp4 基础上加入多包大小（64B/1KB/128KB）和多流并发测试，覆盖更多真实负载场景

二、根据 eBPF 延迟测试结果做优化

wifi_monitor 工具已在代码层面完成，下周在实机上运行并采集延迟数据，重点关注的指标：

• SDIO CMD53 传输延迟分布（P50/P95/P99）：评估 PIO 模式下的寄存器轮询开销是否与上周估计的 ~50ms 调度惩罚一致，为 PIO→DMA 迁移的优先级评估提供实测依据
• TX 帧批量大小与轮询周期：判断当前批量发送策略是否充分利用了描述符环容量，是否存在"频繁小批量"的低效模式
• RX 帧到达间隔：评估中断合并（如果有）和轮询间隔的合理性

根据延迟数据决定优化方向：如果 SDIO 延迟确实占主导（与上周 PIO ~30% 影响占比的估计一致），则优先推进 DMA 替代 PIO；如果帧批量效率低，则优先调整批量发送策略和描述符环大小。

三、todo 项跟进

• net-bench 应用层统计闭环和 /proc/net/snmp 数据填充：根据 SG2002 WiFi 优化的进展，在测试流程稳定后择机推进

总结

本周完成了从 QEMU 虚拟化测试到真实硬件性能工程的重心切换。/proc/net/dev 全部 17 列字段按 Linux 语义实现，为跨内核对比提供了完整、可靠的数据基础；SG2002 WiFi 驱动修复和板端测试路径搭建打通了"修改→刷机→测试→分析"的完整迭代闭环；eBPF 延迟探针为后续的驱动优化提供了细粒度的观测手段。下周将围绕测试流程的自动化完善和 eBPF 延迟数据的实际采集展开，进入"测量→分析→优化"的循环。