测试日期：2026-10-15～2026-10-18
报告日期：2026-10-18
1. 存盘程序优化
1.1 扩大 DMA 缓冲与写入队列
| 项目 |
V1.2 |
V1.3 |
作用 |
| 默认 BD 数量 |
64 |
640 |
增加可暂存的数据量 |
| 每个 BD 大小 |
1,310,720 字节 |
不变 |
保留原有 DMA 数据块大小 |
| DMA 环缓冲总容量 |
80 MiB |
800 MiB |
容量扩大 10 倍，吸收较长写入停顿 |
| 异步写入队列深度 |
16 |
64 |
增加可并行等待完成的写入请求 |
以 160 通道、2 MHz、16 bit 的 640 MB/s 输入计算，80 MiB 和 800 MiB 分别相当于约 0.131 s、1.311 s 的数据量。
1.2 调整文件存储与切换方式
| 项目 |
V1.2 |
V1.3 |
| 文件空间 |
打开文件后随写入扩展，无整文件预分配 |
使用 fallocate 预分配目标文件空间 |
| 文件切换 |
主接收流程排空写入、同步、关闭旧文件，再打开新文件 |
排空旧文件写入后，将同步收尾交给后台线程，切换到提前准备的文件 |
| 后台维护 |
文件创建和同步关闭由主流程承担 |
独立维护线程负责文件预分配、同步关闭及 JSON 更新 |
| 末文件长度 |
物理长度等于已写入长度 |
保留预分配长度，JSON 文件区分有效区与未写零填充尾部 |
| 数据说明 |
BIN，无任务级 JSON 清单 |
BIN + 任务 JSON，记录格式、通道映射、有效范围和同步结果 |
2. 程序优化后获得的实测表现
| 能力 |
实测结果 |
| 3卡、96 通道持续存盘 |
2 MHz、标称 384 MB/s，完成约 1.642 TB 长采，计数一致、无报告丢数 |
| 5 卡、160 通道持续存盘 |
2 MHz、标称 640 MB/s，完成约 1.644 TB 长采，计数、文件大小及填充检查通过 |
| 最新优化 SDK 回归 |
完成约 1.503 TB、470 文件长采，计数、JSON、文件大小及填充检查通过 |
| 写入波动 |
写入完成延迟最高约 439 ms，大缓冲配置随后恢复，未报告丢数 |
| 最终数据交接 |
真实长采中 PL 输出字节增量、DMA 接收量和应用写入量一致，文件均记录同步完成 |
3. 典型测试条件与结果
3.1 测试条件
| 项目 |
条件 |
| 平台 |
DDAQ 开发板，Linux 6.1.30-xilinx-v2023.2 |
| 存储 |
/dev/nvme0n1，ext4，挂载于 /run/media/DDAQ_NVME-nvme0n1 |
| 采集方式 |
PS 配置，stream，每通道 2 MHz，96 或 160 通道 |
| 数据格式 |
int16 小端；96 通道每帧 192 字节，160 通道每帧 320 字节 |
| V1.3 测试配置 |
640 个 BD、800 MiB 环缓冲、写入队列深度 64 |
3.2 代表性结果
| 编号 |
日期 |
测试 |
有效数据量/字节 |
结果 |
| T01 |
10-15 |
V1.2，缓冲较小，96 通道真实存盘 |
343,583,068,992 |
未通过，drop_busy 增加 498,674，退出 1 |
| T02 |
10-15 |
V1.3，96 通道约 15 分钟存盘 |
345,599,700,288 |
计数及 JSON 同步记录通过，退出 0 |
| T03 |
10-15 |
V1.3，96 通道长采，启停约 71 分 35 秒 |
1,641,976,893,120 |
计数及 JSON 同步记录通过，退出 0 |
| T04 |
10-16 |
V1.3，96 通道 DMA 丢弃，约 75 分钟 |
1,714,547,375,232 |
接收量等于丢弃量、计数通过，退出 0 |
| T05 |
10-16 |
V1.3，160 通道长采，启停约 43 分钟 |
1,643,516,875,840 |
计数、JSON、实际文件大小及填充通过，退出 0 |
| T06 |
10-18 |
V1.3，160 通道长采，启停约 39 分 28 秒 |
1,503,131,569,920 |
计数、JSON、实际文件大小及填充通过，退出 0 |
3.3 两次 160 通道长采的文件检查
| 项目 |
T05：10-16 长采 |
T06：10-18 最新长采 |
| BIN 文件数 |
86 |
470 |
| 每文件物理大小/字节 |
19,200,000,000 |
3,200,000,000 |
| 最后文件有效数据/字节 |
11,516,875,840 |
2,331,569,920 |
| 最后文件零填充/字节 |
7,683,124,160 |
868,430,080 |
| 全部文件大小检查 |
通过 |
通过 |
| 完整尾部零填充读取 |
通过 |
通过 |
| JSON 文件同步记录 |
全部为 true |
全部为 true |
| 板端检查退出码 |
0 |
0 |
4. 仍存在的速度波动
| 测试 |
最长写入完成观测延迟 |
周期状态采样中的最大积压 |
| T02：96 通道，约 15 分钟 |
272.400 ms |
47 个 BD，58.75 MiB |
| T03：96 通道长采 |
296.929 ms |
71 个 BD，88.75 MiB |
| T05：160 通道长采 |
439.334 ms |
488 个 BD，610 MiB，占总缓冲 76.25% |
| T06：最新 160 通道长采 |
423.628 ms |
290 个 BD，362.5 MiB，占总缓冲 45.31% |
T06长采中的一次恢复过程：
elapsed=657.1s write_rate=565.141MB/s pending=64 hw_bd=350 done_bd=226 user_bd=64
elapsed=662.1s write_rate=715.638MB/s pending=1 hw_bd=639 done_bd=0 user_bd=1
写入完成短暂滞后后，缓冲得到追赶处理，没有发展为持续积压。
5. 结论
V1.3 通过扩大缓冲、加深队列以及文件预分配和后台维护，改善了长时间采集的写入稳定性。在已测硬件与配置下，完成了 96 通道约 384 MB/s、160 通道约 640 MB/s 输入工况的 TB 级存盘验证，未报告丢数。
本文章使用limfx的vscode插件快速发布