D3.04.4Pipeline latency as the real cause设计研究
网络或渲染延迟经常是同步窗口被突破的实际原因
别名: render latency · network jitter · pipeline
概念解释
同步问题通常不是触觉设计的失误，而是链路延迟造成的。触觉往往要等一个远端事件确认才开始，而这个确认要经过网络往返与渲染排队。屏幕上的动画可以提前播放，触觉却只能等真实事件到达，两者的时间基线因此不同。
机制
同步失败的来源可以分层：本地渲染延迟、输入采样周期、网络往返时间与服务端处理时间。视觉反馈常常由本地预测或乐观更新生成，因此看起来很快；触觉若绑定在确认信号上，就包含了完整往返时间。二者之差正是感知到的错位。抖动比平均延迟更麻烦：稳定的延迟可以被提前补偿，随机波动的延迟无法被单一补偿值覆盖，只能在设计中留出更大的容差。
怎么研究
可分两层测量：链路层面记录端到端各阶段的时间戳，定位延迟主要发生在哪一段；感知层面用同步判断任务测量用户可察觉的偏差。将两者对照，可以判断感知问题是否由链路造成。变量包括网络条件（延迟、抖动、丢包）、渲染负载与设备类型。因变量应包括抖动指标，因为它是补偿策略的主要约束。
边界
若系统采用本地预测，用户在多数情况下感知不到延迟，但在预测失败并回滚时会出现剧烈错位，这种偶发情况往往比稳定延迟更破坏信任。完全离线的场景不存在网络成分，问题只剩渲染与采样延迟。补偿策略也有上限：当延迟超过感知容许范围，任何补偿都只能缩小而不能消除错位。
怎么落地
- 让触觉尽量绑定本地可确定的事件时刻，而不是远端确认到达的时刻。
- 在必须等待远端的情况下，提供本地即时确认，把远端结果作为后续状态更新。
- 监控抖动而不只是平均延迟，并针对抖动设计容差而不是固定补偿。
- 验证方式：在弱网与高负载条件下分别测量端到端时间戳与用户察觉到的偏差，确认感知问题的主要来源已被定位，并检查抖动是否在设计容差内。