docs: 新增 .qoder Repowiki 知识库文档

js/motor/refresh-rate.js

@@ -7,10 +7,14 @@
  *
  * 为什么两条链路不能共用一个值：往返代价差一个数量级。
  *   wifi 250ms（下限 50ms）—— 走无线 + ESP32 HTTP，还要与 GD32 0xC5 主动推送周期对齐；
- *   ecat  50ms（下限 1ms）—— 只是从本机后台 PDO 快照里读一次（经代理实测均值 ≈ 1.4ms），
+ *   ecat  50ms（下限 6ms）—— 只是从本机后台 PDO 快照里读一次（经代理实测均值 ≈ 1.4ms），
  *                 PDO 总线周期由后台循环独立维持（默认 4ms，喂 1000ms 看门狗），
  *                 界面读得快只是显示更跟手，不给总线加负担。
- *                 1ms 的语义是「不限速」而非 1000Hz，见 UNTHROTTLED_MAX_MS。
+ *                 6ms 下限的来由：实测 1ms 档能跑到 ~550Hz，而画面绘制上限由显示器
+ *                 刷新率封顶（本机 160Hz），160Hz 以上那部分轮询没有消费者，
+ *                 纯粹是 HTTP 过路费（每拍 ≈1.6KB 快照，renderer / 网络服务 /
+ *                 browser / Python 代理各被点一次）。填 6 的语义仍是「不限速」，
+ *                 见 UNTHROTTLED_MAX_MS。
  * 共用一个值的实际后果：ECAT 的快值带到 WiFi 上会让 HTTP 请求排队
  * （tickStuck 常亮黄），WiFi 的 250ms 带到 ECAT 上又白白浪费了本地快照的低延迟。
  */
@@ -22,14 +26,15 @@ export const REFRESH_DEFAULTS = { wifi: 250, ecat: 50 };
  * 每条链路允许的**最小**间隔（ms）。这一项按链路分开，是因为下限的成因不同：
  *   wifi 50ms —— 下限来自链路本身：每拍是一次无线 HTTP 往返，再快只会让请求
  *                 排队积压（tickStuck 亮黄），毫无收益。
- *   ecat  1ms —— 读的是本机后台 PDO 快照，没有总线代价，允许"全速跑"。
- *                 注意 1ms **不等于** 1000Hz：单飞语义下上一拍完成才发下一拍，
+ *   ecat  6ms —— 读的是本机后台 PDO 快照，没有总线代价，允许"全速跑"。
+ *                 注意 6ms **不等于** 166Hz：单飞语义下上一拍完成才发下一拍，
  *                 而每拍要过一次 HTTP（代理 → ecat_native → 回来），实测均值
- *                 ≈ 1.4ms，浏览器里 1ms 档实测约 125Hz。填 1 的语义是
+ *                 ≈ 1.8ms，所以 6ms 档实测约 160Hz —— 正好贴着本机 160Hz 屏的
+ *                 绘制上限，再快只是多收一份 HTTP 过路费。填 6 的语义仍是
  *                 "不要人为限速"，相应地要关掉卡顿黄标与理论 Hz 显示，
  *                 见 UNTHROTTLED_MAX_MS。
  */
-export const REFRESH_MIN_BY_TP = { wifi: 50, ecat: 1 };
+export const REFRESH_MIN_BY_TP = { wifi: 50, ecat: 6 };
 /** 兜底最小值：未知链路 id 时用（防御，正常不该出现）。 */
 export const REFRESH_MIN_MS = 50;
 export const REFRESH_MAX_MS = 5000;