端到端延迟是多段串联，优化只对最长的那段有效
别名: 延迟预算 · 关键路径 · latency budget · MTP breakdown
概念解释
头一动到光子进眼睛，中间不是一块延迟，是传感器采样、传输、应用逻辑、GPU、扫描输出、像素发光串起来的和。这个和叫端到端延迟（end-to-end latency），工业上常按运动到光子来测。优化只对当前最长的那一段有效：把已经很短的应用线程再削两毫秒，人感觉不到；显示那一截若占了大半个刷新周期，不碰它，总和就还在。
它讲的是预算怎么分配，不是「这条延迟必须低」那句结论本身。
机制
串联系统的总和等于各段相加，观感由总和决定，改进由瓶颈决定。传感器内部滤波 2 ms、USB 再等一个包 1 ms、应用模拟 3 ms、GPU 8 ms、排队扫描 8 ms、发光再拖 2 ms——合计二十出头。把模拟从 3 削到 1，总和几乎不动；把 GPU 和扫描从 16 削到 8，人才能感到世界黏上头。
刷新周期本身就是一块硬预算：90 Hz 大约 11 ms 一帧，扫出加余辉会吃掉其中一截，应用再慢就只能排队到下一帧。这不是软件「还可以再优化一下」，是队列位置。Amdahl 在这里很具体：加速非瓶颈段，加速比为 1。
所以测量必须分段。只报一个总数，团队会去改最熟的那一层（通常是应用），而熟的那一层往往不是最长的。
怎么研究
用光电二极管贴在镜片前对闪烁图案计时，同时在驱动里打各段时间戳（IMU 中断、提交、GPU fence、vsync），把一次点头拆成瀑布图。再单独加长或缩短某一段（固定其他段），看检测阈和不适是否跟着那一段走。
自变量：被拉长的是哪一段、该段的绝对时长、总时长是否保持不变。 因变量：分段耗时、点头到亮度变化的延迟、主观「世界发黏」评分。
关键对照：总和相同、瓶颈不同。若只有瓶颈段被拉长时评分才升，就能把「改错层」从「延迟高」里分开。
边界
云渲染、分体计算把传输段变成可能的新瓶颈，本机 GPU 再快也填不上网络抖动。光学透视没有「虚拟光子」这一段，延迟结构不同，不能拿同一张瀑布图去套。固定注视、几乎不转头的任务对总和不敏感，瓶颈测不出来。实验室用的插帧、异步时间扭曲会把「应用段」从关键路径上摘掉——测到的瓶颈会转移到扫描和发光，这正是运行时已经做过一次预算重写，解释结果时要标明。
怎么落地
- 先画瀑布图再开工：传感器、传输、CPU、GPU、扫描、发光各占多少，只改当前最长的一截。
- 把刷新周期当硬上限来排队列，而不是当「平均帧率还行」的统计。
- 应用侧优化若瀑布图上不是最长段，不要当成延迟项目的完成条件。
- 验证：改完之后重采瀑布图。总和下降而最长段几乎没动，说明改错层；最长段变短、观感仍差，再去看波动和丢帧，而不是继续削同一段。