本文前言:
根据两份 software-build.md,在你"硬件部分已经完成配置"的前提下,软件部署可以按下面这套顺序做(硬件:https://blog.csdn.net/Rthan/article/details/160113548?spm=1001.2014.3001.5502)。 先确认板卡已经能正常启动 Linux,并且底层硬件接口已经可用,包括 TSN 相关网口、DMA/UIO、时钟/TSU、GCL/转发表对应驱动资源。两份软件都不是在仓库根目录编译,而是在各自的 Software 目录下:
- 交换机软件目录:xx\Ziggo-CaaS-Switch-main\Ziggo-CaaS-Switch-main\Software\Time-Synchronization
- 设备软件目录:xx\Ziggo-Device-main\Ziggo-Device-main\Software

另外,交换机文档里写"build 后有 time_sync_app 和 switch_config",但实际 CMakeLists.txt 生成的是 time_sync 和 switch_config。设备侧实际生成的是 time_sync 和 pkt_gen。
具体步骤:
1. 准备配置文件
两种设备都需要同一套调度结果导出的两个 JSON:
-
config.json:拓扑、节点类型、MAC、PTP 端口状态、链路、转发表
-
schedule.json:链路调度窗口、交换机计算窗口
仓库里有示例配置可参考:
-
交换机示例:...\Software\Time-Synchronization\config\
-
设备示例:...\Software\config\
你需要把 CNC/调度算法输出的 [topology]-config.json 和 [topology]-schedule.json 选定为本次实验使用版本。
2. 编译交换机软件
在交换机板上或你的目标 Linux 编译环境中进入:
bash
cd /path/to/Ziggo-CaaS-Switch-main/Ziggo-CaaS-Switch-main/Software/Time-Synchronization
mkdir build
cd build
cmake ..
make
成功后应得到:
-
build/time_sync
-
build/switch_config
然后把配置文件复制到 build 目录,并固定命名为文档要求的名字:
bash
cp ../config/<your-topology>-config.json ./config.json
cp ../config/<your-topology>-schedule.json ./schedule.json
3. 编译设备软件
进入设备软件目录:
bash
cd /path/to/Ziggo-Device-main/Ziggo-Device-main/Software
mkdir build
cd build
cmake ..
make
成功后应得到:
-
build/time_sync
-
build/pkt_gen
同样把配置文件复制到 build 目录:
bash
cp ../config/<your-topology>-config.json ./config.json
cp ../config/<your-topology>-schedule.json ./schedule.json
4. 板端部署与启动顺序
建议先把所有板子的可执行文件和对应 config.json、schedule.json 都放到各自板卡本地,再开始启动。运行顺序建议这样:
-
先启动所有交换机的时间同步
-
再下发交换机 GCL 和转发表
-
再启动设备的时间同步
-
最后启动设备发包
交换机启动
在交换机 build 目录下:
bash
taskset -c 1 ./time_sync
文档明确建议把时间同步绑到一个 CPU 核上,避免内核错误或崩溃。日志级别可选:
bash
taskset -c 1 ./time_sync -l w
taskset -c 1 ./time_sync -l i
taskset -c 1 ./time_sync -l t
其中 -l t 最详细。time_sync 需要持续运行,不是一次性程序。
时间同步起来后,再执行:
bash
./switch_config
这一步负责把 GCL 和交换机转发表写进去。
设备启动
在设备 build 目录下先启动时间同步:
bash
./time_sync
再启动关键业务流发包:
bash
./pkt_gen
5. 联调时的推荐执行顺序
如果你现在是一个"交换机 + 多设备"的系统,建议按这个顺序上电后的软件部署:
-
每台交换机编译并准备好 build/time_sync、build/switch_config
-
每台设备编译并准备好 build/time_sync、build/pkt_gen
-
给所有节点放入与当前实验一致的 config.json / schedule.json
-
启动所有交换机 time_sync
-
观察同步日志,确认主从关系和邻居同步正常
-
执行所有交换机 switch_config
-
启动所有设备 time_sync
-
启动源设备 pkt_gen
-
在接收端或日志文件中分析时延/抖动
-
结果检查
设备侧文档给了两种分析方式。
如果直接在设备上分析,time_sync 运行过程中会生成:
-
build/packet_log.csv
-
build/critical_log.csv
如果要离线分析,则需要切到设备仓库的 offline_analyze 分支,对接另一台 Linux PC 抓包,再用:
bash
python ./analyze_packet.py <capture-file> --step <interval>