【星闪 SLE 学习笔记 07】连接参数如何影响时延？H3863 双板 2000 个 RTT 样本实测

【星闪 SLE 学习笔记 07】连接参数如何影响时延？H3863 双板 2000 个 RTT 样本实测

前面几篇里，我已经用两块 BearPi-Pico H3863 跑通了 SLE UART 双向通信，继续拆解了 SSAP 服务、连接配对、MTU、负载长度和有效吞吐率。做到这里，一个问题自然出现了：

SLE 经常被提到“低时延”，但在我手里的两块开发板上，时延究竟该怎么测？连接参数改变以后，又会发生什么？

这件事看起来只是给发送和接收各加一个时间戳，真正动手后却发现有不少陷阱。例如，两块板的时钟没有同步，COM3 和 COM4 的日志时间不能直接相减；SDK 中打印了 sle_low_latency_rx_enable，也不代表对应 API 真的执行了；sle_update_connect_param() 返回成功，也只说明请求提交成功，不能证明参数已经生效。

所以这篇不追求一个漂亮的“最低时延”数字，而是先把测量口径、参数更新证据和实验边界做扎实，再比较四种连接参数下的应用层 RTT。

一、先说结论

本次使用两块 BearPi-Pico H3863：

• Server：带外置 2.4 GHz 天线，COM4；
• Client：COM3；
• 固定 16 字节测试包；
• 每组先预热 20 包，再统计 500 包；
• 四组共取得 2000 个正式 RTT 样本；
• 四组均无超时、无内容不匹配、无提交错误、无确认错误；
• Server 每组都完整收到并回显 520 包。

结果如下：

在本次硬件、SDK 和测试路径下，缩短连接间隔并将 latency 设为 0，RTT 的中心位置和长尾都明显下降；low-power 参数仍能可靠完成全部数据交换，但代价是更高的等待时间和更明显的长尾。

不过，这些数字只能代表本文的实验条件，不能写成 SLE 标准规定的固定时延，也不能当作 H3863 在所有环境下的性能承诺。

二、为什么不能用两个串口时间相减

最直观的想法是：Client 发送时记下 COM3 的时间，Server 收到时记下 COM4 的时间，两者相减就是单向时延。

这个方法在当前条件下并不成立，因为它至少混入了：

• 两块开发板不同的时钟起点和频率误差；
• 两个 USB 转串口芯片的缓存；
• Windows 串口调度；
• QCOM 读取和界面刷新的延迟；
• 固件格式化日志以及 UART 输出所需时间。

更关键的是，两块开发板没有做时钟同步。因此：

Server 接收时间 – Client 发送时间

不能被当作可信的单向无线时延。

我最终选择测量 RTT，并让开始时间和结束时间都来自 Client 的同一个 uapi_tcxo_get_us() 计数器。这样不需要对齐两块板的时钟。

三、本文测到的到底是什么

本次测量路径如下：

Client 记录 t_send
↓
Client 调用 ssapc_write_req()
↓
Server 的 SSAPS 写请求回调收到数据
↓
Server 通过 notification 原样回显
↓
Client notification 回调收到对应数据
↓
Client 记录 t_recv，并计算 t_recv – t_send

所以本文测量的是：

SSAP 写请求—notification 回显路径的应用层 RTT。

它包含 Client 和 Server 两端协议处理、双向无线传输、Server 回调处理及 notification 提交等环节。它不是单向空口时延，也不是纯射频传播时间，更不是 SLE 的理论最低时延。

这里还有一个必须说明的条件：当前调试固件仍存在部分 SDK 日志，因此结果也可能包含调试输出对任务调度和串口阻塞造成的影响。更准确的表述应该是“当前调试固件条件下的应用层 RTT”。

四、连接参数分别控制什么

海思 WS63 官方接口文档给出的连接参数中，interval_min 和 interval_max 的单位是 0.25 ms，范围为 30～16000，即 7.5 ms～4 s；max_latency 表示最大休眠连接间隔；supervision_timeout 的单位是 10 ms。海思 WS63 Connection API

这几个参数可以先这样理解：

• interval：链路调度的基本时间间隔；
• max_latency：允许设备在没有业务时跳过的连接间隔数量；
• supervision_timeout：链路长时间没有有效通信后，用于判断连接失效的超时上限。

缩短 interval，通常意味着设备更频繁地获得通信机会，等待下一次调度的时间可能缩短；增大 interval 并允许更大的 latency，设备可能获得更多休眠机会，但新数据到达后也可能等待更久。

这里的功耗关系只是机制上的定性解释。本次没有使用功耗仪测电流，因此不能根据“low-power”这个名字写出任何节能百分比。

五、参数不是随便填的

海思官方“连接参数动态更新”示例提供了三种 profile：WS63 连接参数动态更新示例

官方示例还检查：

timeout_scaled = supervision_timeout * 20;
max_connection_gap = (max_latency + 1) * interval_max;

并要求：

timeout_scaled > max_connection_gap

也就是说，参数不仅要分别处于合法范围，组合起来也必须满足监管超时约束。

六、API 返回成功，不等于参数已经生效

参数更新使用：

sle_connection_param_update_t param = {
.conn_id = g_sle_uart_conn_id,
.interval_min = 50,
.interval_max = 50,
.max_latency = 0,
.supervision_timeout = 500,
};

errcode_t ret = sle_update_connect_param(&param);

但 ret == ERRCODE_SUCC 只能说明参数更新请求成功提交。最终执行结果需要通过连接管理回调获取：

connect_param_update_req_cb
connect_param_update_cb

因此我在 Client 和 Server 两端都注册了请求回调和完成回调。以 balanced 组为例，Client 日志为：

[CONN_PARAM][CLIENT_SUBMIT_RESULT] ret=0x0
[CONN_PARAM][CLIENT_UPDATED] conn_id=0 status=0x0
interval=50 latency=0 supervision=500
[CONN_PARAM][SUMMARY] … result=PASS

Server 同时记录到：

[CONN_PARAM][SERVER_REQ] conn_id=0 status=0x0
interval_min=50 interval_max=50 max_latency=0 supervision=500

[CONN_PARAM][SERVER_UPDATED] conn_id=0 status=0x0
interval=50 latency=0 supervision=500

只有同时满足下面三点，我才把该参数组纳入 RTT 对比：

七、测试包与匹配方法

测试包固定为 16 字节：

Server 不修改内容，直接通过 notification 回显。Client 收到回包后检查 magic、seq、发送时间戳和固定字段。只有内容完全匹配，才计算本次 RTT。

测试采用顺序请求：同一时间只保留一个未完成样本。Client 必须先收到写确认和对应 notification，才发送下一包。这样牺牲了并发吞吐能力，但简化了 RTT 配对，也避免乱序造成误判。

每组测试条件统一为：

• 20 包预热，不计入统计；
• 500 个正式样本；
• 每次回显完成后等待 20 ms；
• 不逐包输出 RTT；
• 测试结束后统一计算统计量和直方图；
• Server 同时检查总包数、序号、内容和回显提交结果。

八、为什么不只看平均值

时延数据很容易出现长尾。只给平均值，可能掩盖少量但明显偏慢的样本。因此我同时统计：

• min：本轮最小样本，但不代表稳定最低时延；
• median：典型水平，50% 样本不超过它；
• P95：95% 样本不超过它；
• P99：更靠近尾部，用来观察少量慢样本；
• max：最慢样本；
• timeout 和各类错误：单独报告，不能静默丢弃。

本次每组 500 个正式样本，P95 和 P99 可以用于观察趋势，但仍不是严格的服务等级保证。

九、四组结果逐项分析

9.1 默认基线

默认配置不主动调用参数更新 API：

min = 51.638 ms
median = 59.162 ms
avg = 58.982 ms
P95 = 64.233 ms
P99 = 97.049 ms
max = 117.189 ms

500 个样本中，496 个位于 50～100 ms，4 个不低于 100 ms。默认组提供了后续对比的基准，但由于没有额外查询当前控制器默认参数，本篇不会反推或猜测它实际采用了什么 interval。

9.2 balanced：50 / 0 / 500

min = 26.414 ms
median = 28.599 ms
avg = 28.855 ms
P95 = 34.111 ms
P99 = 36.290 ms
max = 43.907 ms

全部 500 个样本都位于 20～50 ms。与默认基线相比，不只是中位数下降，P99 和最大值也明显收紧。

9.3 low-latency：30 / 0 / 200

min = 16.306 ms
median = 18.633 ms
avg = 18.367 ms
P95 = 20.074 ms
P99 = 21.167 ms
max = 27.959 ms

454 个样本位于 10～20 ms，46 个位于 20～50 ms，没有样本达到 50 ms。当前四组中，这组 RTT 最低，分布也最集中。

9.4 low-power：400 / 49 / 1200

min = 219.917 ms
median = 223.320 ms
avg = 239.770 ms
P95 = 321.389 ms
P99 = 421.094 ms
max = 1071.069 ms

500 个样本全部不低于 100 ms，最大值超过 1 秒。但这一组仍然没有超时或错包，Server 也完整处理了全部 520 包。

这很好地说明了一点：

链路能可靠完成数据交换，不代表它同时满足低时延需求。

十、“low-latency 参数组”不等于低时延专用 API

当前 UART Client 建链后原本会打印：

[sle uart client] sle_low_latency_rx_enable

但我检查源码后发现，对应位置只有 osal_printk()，没有真正调用 sle_low_latency_rx_enable()。

另一方面，SDK 确实公开了低时延相关接口和 125 Hz～8 kHz 的调度速率枚举，也提供 sle_low_latency_set()、低时延 TX/RX 回调注册及使能接口。海思 WS63 Connection API SLE Low Latency API

但这些专用接口不能和普通 SSAP 的 ssapc_write_req() 路径混为一谈。

本文中的 low-latency 只是官方连接参数示例对 30 / 0 / 200 这组参数的命名。本次实验没有调用 sle_low_latency_set()，也没有验证专用低时延 TX/RX 数据通路。因此本文的结果只能用于说明普通 SSAP 回显路径受到连接参数变化的影响。

十一、我从这次实验中得到的认识

第一，时延测试首先是测量口径问题。没有同步的双板时钟不能直接计算单向时延；使用同一设备、同一计数器测 RTT，才能避开最明显的时钟偏差。

第二，配置参数不能只看调用代码。同步返回、异步回调和最终实际值组成了一条完整证据链，缺少任何一步都不应声称参数已经生效。

第三，中位数只能描述典型样本，P95、P99 和最大值才能暴露长尾。low-power 组的中位数约为 223 ms，但最大值超过 1 秒，如果只报告平均值，就很难看清这种差异。

第四，参数选择本质上是业务取舍。实时控制和低频传感上报关心的指标不同，不能把某一组参数简单称为“最好”。本文只实测了 RTT，没有测功耗，所以能确认时延变化，却不能量化功耗收益。

第五，日志文字不是接口调用证据。看到 sle_low_latency_rx_enable 这行输出时，我一开始也容易把它理解成“低时延已开启”；回到源码检查后才发现它只是打印。这也是继续深入阅读 SDK 的价值。

十二、实验边界

本文结论成立的范围是：

• 两块 BearPi-Pico H3863；
• 当前使用的官方软件包与 SDK；
• 当前板间距离、摆放、供电和射频环境；
• 16 字节负载；
• 普通 SSAP 写请求与 notification 回显路径；
• 当前调试固件和日志配置；
• 每组单轮 500 个正式样本。

本文没有完成：

• 时钟同步后的单向空口时延测量；
• 示波器或逻辑分析仪外部引脚测量；
• 多距离、多干扰环境重复实验；
• 每个配置多轮重复后的置信区间；
• 电流与能耗测量；
• sle_low_latency_set() 及专用低时延 TX/RX 路径验证。

因此，文章中所有数字都应理解为一次可复现的开发板实验记录，而不是宣传指标。

十三、小结

这次实验最终得到的不只是四组 RTT 数字，更重要的是建立了一套相对可信的验证流程：

定义测量边界
→ 使用 Client 单时钟测 RTT
→ 对测试包做序号和内容匹配
→ 同时检查 API 返回与异步回调
→ 以实际生效参数命名实验组
→ 固定负载、预热、样本数和发送间隔
→ 报告中位数、P95、P99、最大值及全部错误项

在本次实验条件下，30 / 0 / 200 的连接参数组获得了最低、最集中的应用层 RTT；400 / 49 / 1200 仍能可靠通信，但 RTT 和长尾明显增大。这与连接调度时间尺度的变化方向一致。

下一篇将继续沿着“可验证”这条路线深入，不把 API 名称、日志文字和实际生效状态混在一起。

参考资料

本地 SDK 主要参考文件：

include/middleware/services/bts/sle/sle_connection_manager.h
include/middleware/services/bts/sle/sle_low_latency.h
include/driver/tcxo.h

application/samples/products/sle_uart/sle_uart.c
application/samples/products/sle_uart/sle_uart_client/sle_uart_client.c
application/samples/products/sle_uart/sle_uart_server/sle_uart_server.c