外观
Frame Pacing Jitter：帧节奏离散度
Frame Pacing Jitter 用一个容易解释的值描述“帧间隔是否忽快忽慢”。即使平均 FrameTime 看起来正常，如果长尾经常拉开，用户仍可能感到明显顿挫。
最新验收状态 · 2026-10-23
正式38/66、剩28项。Jitter全新无参考协议5/5通过，固定600/600槽有效、888条Raw/Collector/CSV逐点一致，五轮长尾与恢复方向及SHA保全通过（E4）。标记NO_REFERENCE_ACCEPTED_OWNER_POLICY，物理精度未校准；旧3/5及r4失败不改。下一项按原顺序为平均FPS。网站/Webhook及远程同步欠项单列，公证暂缓，仅内部测试。 本批结果。
e01：事件存在、完整窗口与观察覆盖分别判断
预先启动35秒可控负载、关闭全部直连服务后录制，确认录制期间无控制动作。Display确实产生28条非元数据事件，但Trace仅0.331324秒即断连；时钟桥证明负载/Trace重叠同样不足10秒。不能将短片段拼成完整窗，也不能把“完整对照不可用”写成“系统没有任何事件”。这是当前环境E4结果，不是永久能力或硬件根因结论。e01结果。
资源采样需记录异常类型、阶段、时刻及进程生命。NoSuchProcess后独立复查确认消失或PID换生命，才记已退出；AccessDenied、Zombie、仍存活或无法复查均记未解决读取，不补0。e01按此合同51点完整覆盖、无未解决错误；旧d01未知点不追认豁免。该方法适用于外部工具采样，不能声称捕捉采样间瞬时峰。
历史状态 · r4与早期参考调查 · 2026-10-23
整体正式验收为 37/66，Jitter累计 3/5。r4已完整采集并独立复核，但固定Metal参考窗只有6/7合格，故r4不计轮次；阶段方向门未通过，整项与物理校准仍未通过。r4的Session seal/SHA、Raw oracle与Raw/Collector/CSV一致性、固定120槽及Fixture释放门通过；这些软件与保全事实不能抵消参考窗失败。
失败窗位于long-callback阶段+25秒：一条FrameLifetime没有对应的Metal presentedTime。独立时钟复算确认该事件落在Fixture刻意延迟的回调期间、下一drawable提交前；它解释了此用例两源覆盖范围不同，但没有证明具体显示语义或硬件/软件根因。Metal候选其余六个冻结窗合格，整窗仍partial。后续Frame Lifetimes进程名attach短测在目标进程存在、DVT/xcdevice守卫通过时仍返回Cannot find process matching name，没有生成trace；只拒绝该配置，不能证明硬件或产品故障，也未确认参考不可用。referenceUnavailableConfirmed=false、referenceAccuracyValidated=false、formalFiveRoundsPassed=false保持；Jitter仍3/5、整体37/66。后续资格测试先处理xctrace通道并重做新鲜守卫；Owner已授权自主清理易失预览，保存Raw、Session与失败证据继续保全，最新处理见下方c02增量。详见2026-10-23 r4诊断与参考用例及固定窗资格复核。
Display d01：自然结束与通道、资源证据分别判断 · 2026-10-23
无手机控制动作的2秒短录制可以自然达到时间限制（TOC2.337262秒），同时区间日志仍有kAMD连接错误，观察器也可能缺少一次RSS读取；本次严格门因此失败。不要将exit0或达到时间限制当成全部门通过，也不要把日志中的连接错误统一改写成Trace因设备断连而结束。本次Trace明确为Time limit reached，xctrace输出没有Device got disconnected。d01原始事实与边界。
进程内存采样若把NoSuchProcess、AccessDenied和Zombie合并为一个unknown计数，事后无法证明它只是正常退出竞态。应在下一版观察合同中记录具体异常类型、采样时刻和生命状态，失败样本保留，不能对已发生的unknown豁免。此方法适用于外部工具的有界资源观察，不改变采样式峰值的覆盖限制。本轮屏幕空闲且只有时钟/设备元数据，零时序事件也不能确认活动负载下不存在可用参考。当前正式仍3/5、整体37/66，无新的参考/指标通过结论。
Display c02：元数据不等于逐帧参考 · 2026-10-23
c02的唯一35秒Fixture run完整封存、旧证据SHA一致，但Trace实际只有0.343416秒并报告断连，未通过完整录制门。定向XML导出共2行：时钟映射和显示设备信息各1行，其余选定表0行，逐帧事件为0。原先在每个XML节点内查schema的解析不充分；联合导出中有些节点仅带TOC位置XPath，必须按真实run/data/table序号回查schema，再将time-info、device-display-info与时序事件分开。表有行、显示分辨率或标称刷新率存在，都不能代替连续呈现时刻。此为E3工具数据结构校核，Fixture封存属于E4，均不代表Jitter精度通过。结果与解析校核。
Owner已授权自主处理测试数据；203张内存预览已在95个保存Session全终态后随Perfowl退出清除，保存证据保留。后续实际CoreDevice详情/App服务查询恢复；下一步先验证无控制动作的2秒录制通道。服务查询成功仍不足以证明完整录制或参考可配对，当前Jitter仍3/5、整体37/66，所有参考/正式五轮通过标记保持false。
Display c01 设备通道资格失败 · 2026-10-23
一次新的 Display-only xctrace --all-processes 资格尝试收到 record-start 通知，唯一的 P95 冷请求被消费，Fixture 在35.008秒后按预期取消并释放负载；独立回读确认旧 run、请求与gate原件保持一致。但 Trace 观察仅12.087秒，尽管命令退出码为0，原始日志报告设备断连；系统日志还记录 usage assertion 获取失败和 kAMDNotConnectedError。Display 表结构可识别，但本次选定表导出为0个事件行，不能进行逐帧时间/显示身份核验，也不能与Fixture呈现数据配对。
这组事实只拒绝该次 Trace 通道，不表示 Jitter 数据异常，也不能确认参考不可用。直接设备服务当时处于打开状态与 Instruments 连接失败在时间上重叠，服务占用冲突是待验证假设；后续 Lockdown /AFC 回读成功不能排除录制期间短暂断连。复现时必须核实实际录制墙钟及原始断连日志，不能只看 exit code 0；Trace需至少覆盖39.5秒且含可配对逐帧事件才准入。下一次资格尝试先关闭直连 DVT/AFC 服务后启动 Instruments，再在 record-start 后短时重连执行唯一Fixture启动并立即关闭直连通道。当前正式仍3/5、整体37/66，referenceUnavailableConfirmed=false、referenceAccuracyValidated=false，不进入下一指标。此为E3设备通道观察，不是物理精度结论。详情见Display原生DVT冷启动资格方案与c01复核。
历史状态快照 · r1复核 · 2026-10-23
整体正式验收仍为 37/66；Jitter 当前 1/5，整项尚未验收。正式r1的7个预先冻结 Metal 对照窗全部合格，阶段方向门通过；在这7窗内，Metal独立重算与Raw oracle的Jitter最大差0.000001ms。Session 179个样本中141个为valid，全部179条Raw oracle、Collector Metric与CSV的值、quality、窗口及receipt身份逐点一致，未消费Raw尾部为0。
全窗 Metal 报告仍为 partial：129/141个valid发表窗通过物理配对，另外12个未选窗未获物理参考资格；不对未选窗声明精度。固定窗合同下r1计为一轮，但不代表五轮通过或物理精度已校准。referenceAccuracyValidated=false、formalFiveRoundsPassed=false 保持。Frame Report v4从保全帧事件重算的末窗质量为source-gap，值为null、样本数0；缺值没有被写成0。下一步是在同一独占attempt中完成r2前的手机通道、目标身份、历史SHA、容量和前缀新鲜复核。Owner确认手机永不锁屏；不需要解锁操作。详细结果与证据边界见2026-10-23正式首轮复核。
1. 定义 / 概念
Perfowl 第一版把 Jitter 定义为同一滚动窗口内：
text
P95(FrameTime) - P50(FrameTime)它衡量的是长尾相对典型帧间隔多出了多少，而不是物理显示抖动传感器值。
2. Scope 与 Unit / 单位
| 字段 | 合同 |
|---|---|
| metricID | ios.frame.pacing_jitter |
| Scope | foreground-device |
| Unit / 单位 | milliseconds |
| source | activitytrace-framelifetime |
| definitionVersion | activitytrace-framelifetime-jitter.v1 |
3. 系统服务 / 采集调用
Jitter 没有独立设备服务。逐帧事实来自 Instruments ActivityTrace 服务 com.apple.instruments.server.services.activitytracetap，通过 DTX 获取 CoreAnimation / IOMFBServer 的 FrameLifetime signpost，scope 为 foreground-device。
Sidecar 依赖 pymobiledevice3 11.3.1 的 ActivityTraceTap(provider, enable_http_archive_logging=False) 传输内核；Perfowl 自研的 ActivityTraceFrameLifetimeRawAdapter、FrameLifetimeDecoder 和严格白名单层负责适配与解码，不调用另一套设备采集库。实时数值由 P95FrameWindow.observe() / snapshot() 与 RealtimeMetricProjector 发布；新策略标记的 Jitter 复用 P95 收据中的同窗样本。旧的未标记历史回放仍走 DisplayPerformanceProjector 兼容路径。封存报告由 analyze_display_frames() 调用 _activity_trace_jitter_summary() 单独总结末窗。
4. 公式 / 计算方式
实时窗口与 P95 一致：最近 10 秒，区间为 (windowLeftNs, windowRightNs]。每个 FrameTime 先由原生 Mach ticks 计算并舍入到 6 位小数：
text
intervalNs_i = floor((endMachTicks_i - previousPresentationMachTicks_i)
* machTimebaseNumer / machTimebaseDenom)
FrameTimeMs_i = round(intervalNs_i / 1,000,000, 6)
window = valid FrameTimeMs in (right - 10,000,000,000 ns, right]
n < 5 → value=null, quality=warmup
P50 = median(window) # 偶数样本取中间两值的算术平均
P95rank = ceil(0.95 * n) = floor((95*n + 99) / 100)
P95 = round(sorted(window)[P95rank - 1], 6)
JitterMs = round(P95 - P50, 6)实时窗口右端以最后一帧的原生 presentation 时间映射到 host publication cut；封存报告摘要则以最后一帧原生 presentation 时间为右端，不把 Session 全程汇总冒充滚动值。实时窗口最多保留 4,096 点，超过上限失效关闭；窗口快照若来源静默超过 1 秒则置空并标 stale-source。
5. 为什么第一版不用标准差作为主值
标准差会受到极端离群帧明显影响，而且对于测试人员来说不如“较差长尾比典型帧慢多少毫秒”直观。P95 - P50 不是唯一可能的帧稳定性定义，但它具有：
- 公式简单；
- 对极少数极端值更鲁棒；
- 能直接与 P50 / P95 对照；
- 跨 Session 回归容易解释。
6. 示例
稳定场景：
text
P50 = 16.7 ms
P95 = 18.2 ms
Jitter = 1.5 ms长尾明显场景：
text
P50 = 16.7 ms
P95 = 48.0 ms
Jitter = 31.3 ms第二种情况下典型帧仍接近 16.7ms，但较差一批帧已经明显脱离正常节奏。
7. Quality / missing
Jitter 必须与 P95 使用同一组经过来源验证的 valid FrameTime 和同一发表时点窗口。target PID / generation、sourceEpoch 、reconnect generation、timebase、前后台状态或主显示上下文变化会清窗口；明确的 warmup、discontinuity、source-gap、无效来源、乱序或采集 drop 会使当前段重新 warmup。sourceEpoch 必须是正整数、reconnect generation 必须是非负整数；PID / generation 若存在必须是正整数，显示 ID 必须是非负整数。布尔、字符串、浮点或越界值不做强制转换，封存摘要置 null/unsupported-schema 并清空当前段。其他 display 的事件不能刷新主 display 的值。少于 5 个样本为 warmup；目标 App 在后台为 not-foreground；来源超出 freshness 门时置 null 并保留实际质量；FrameTime 缺失、非有限、零或负数均不发表，缺值不延续旧数值，也不补 0。若 P95 与 P50 相同，合法 Jitter 可以是数值 0。
2026-10-22 · 与 P95 共享窗口的验收合同
公式仍是 P95 - P50，不改变历史结果。新的验收合同要求 Jitter 从与 P95 相同、受身份/来源/原生时间/连续性验证的 10 秒样本窗口派生，并在产品 Raw oracle 中逐发表点独立复算。共享窗口实现、软件边界测试和 120Hz 合成规模基准已完成 E2；真机五轮尚未开始，正式验收仍为 0/5，不能据此描述为 E4 可用。验收方案与实施记录。
独立物理参考候选为自有测试 App 的 Metal MTLDrawable.presentedTime。Apple 将其定义为 drawable 实际显示的 host time，并规定值 0.0 表示尚未呈现或关联帧已丢弃；必须保留该哨兵和记录，仅当时钟桥、窗口覆盖与事件双向对应合格时才能用于同窗对照。Apple MTLDrawable.presentedTime。CADisplayLink 的 timestamp / targetTimestamp 说明显示时序与调度，不单独证明某个 drawable 实际上屏。Apple CADisplayLink。
Apple Instruments 的 Animation Hitches 模板能展示帧生命周期与显示垂直同步，并用于分析渲染链路中的 hitch；这不代表它与 P95(FrameTime)-P50(FrameTime) 是同一指标。Apple Understanding hitches 此主机在 2026-10-21 的 5 秒资格探测达到 933,773,312 bytes RSS，超过 805,306,368-byte 资源门；后续 trace 表导出也因 RSS 超限失败、输出为 0 bytes。刷新率工具资格记录 这只证明当时的工具配置未通过资源门，不证明设备故障或 trace 源没有数据。不要复跑同一探测或放宽资源上限。xctrace export 可从实际 trace 导出 XML，但只有在一个已通过资源门的新 trace 中确认逐帧时刻、可核时钟域和可绑定身份后，才可评估同窗全事件对应；hitch 汇总值或界面轨道不能替代逐帧 Jitter 参考。Apple Xcode command-line tools。
独立上屏参考的逐窗资格
自有 Metal MTLDrawable.presentedTime 只有在新测试同一设备时钟下，逐帧匹配到 ActivityTrace FrameLifetime 的完整10秒窗口后，才是本指标的可用物理对照。资格检查须核真实时间基与双钟括号；在固定100µs边界内唯一一对一匹配每个端点；核对 Raw 前驱、presented 时间和事件顺序；并证明窗口内无额外/缺失帧、无 display/source 代际切换。0、负值、缺失、倒退、未匹配及含糊匹配都必须保留并使受影响窗口不合格。CADisplayLink、GPU完成回调、请求频率、局部窗口或产品收据不能补齐覆盖缺口。
物理 Jitter 需独立地从连续 Metal presented 时间差重算FrameTime，再对同一 (left,right] 样本集合计算 P50、nearest-rank P95 与 P95-P50。端点配对误差上限为100µs时，Jitter比对容差固定为0.400002ms；禁止看完样本后调宽。五轮全部预期有效发表窗均通过，才可称物理精度已校准。部分窗口可以诊断差异，但不证明整个指标精度，也不等于确认没有参考。只有实际可用候选及可控测试路径都已检查且没有任何可完成的独立对照时，才可按Owner政策验收并加 NO_REFERENCE_ACCEPTED_OWNER_POLICY；标记不改变 referenceAccuracyValidated=false。
逐窗审计时，窗口范围内的 warmup 或断点锚点也必须与 Metal 上屏行配对，证明两边事件覆盖完整；锚点自身不算 Jitter interval。它只在某条 valid FrameTime 确实以该帧为前驱时参与该 interval 的重算。工具的原件校验与配对合同见Metal 参考审计器实现记录。
r4 未配对事件与候选覆盖范围 · 2026-10-23
FrameLifetime Raw、Fixture请求/提交时间及双钟offset独立复算后，固定窗中的未配对事件位于81.015125 ms主线程延迟期间；前后Raw间隔为16.639708 ms与66.553125 ms，前后Metal drawable的 presentedTime 间隔为83.192833 ms。当前证据确认该时刻尚无下一drawable提交，故Metal逐drawable记录没有可配对行。它未证明FrameLifetime记录对应重复扫描、别的Surface或任何具体机制。复核及复现设计见独立诊断记录；私有原件与独立收据仍在attempt-04。
Frame Lifetimes 进程名 attach 失败边界 · 2026-10-23
本机Xcode xctrace支持按进程名--attach <name>（Xcode命令行说明见Apple Xcode 12 Release Notes），但一次2秒设备短测在目标进程已由DVT读取且xcdevice枚举可用时，仍以exit code 19返回Cannot find process matching name，没有产出trace。该尝试的xctrace状态为connecting；进程树RSS、输出字节、墙钟和容量都在冻结资源门内，分离复核确认未建立新Session/run或修改工作台预览。此E4结果只拒绝该次attach配置；它不能证明硬件、Perfowl产品故障或参考源不可用，也不能把全手机写入记作0。复现时先用只读DVT与xcdevice守卫确认身份/进程，再记录xctrace stderr及trace是否生成；不要反复执行同一配置或用部分trace替代逐帧证据。完整结果与分离复核。
本机可见 Frame Lifetimes 与 Display Instruments，但可见不代表目标设备上可用。全进程、PID、进程名和GUI短测目前都未通过准入；attempt-04只得到表schema、没有逐帧行，且观察器超过45秒墙钟门。当前不重试这些配置。该次历史检查保留了203张预览；Owner随后授权自主清理，预览已随正常退出清除，不再构成当前阻塞。后续候选与决策见页首最新增量。任何候选通过后，仍需新独占attempt按现有140秒LabP95配方、固定七窗、完整Raw事件覆盖、100 µs端点界和0.400002 ms差值界完成同场资格；不复跑超资源门的Animation Hitches设置，也不提前标记为无参考。
Frame Lifetimes 表结构与事件数据的证据边界 · 2026-10-23
一次 Instruments GUI 短测能从 xctrace export 读取 coreanimation-lifetime-interval 表的16个字段定义，但没有逐帧事件行；界面也显示 No Graphs / No Data。这只证明Trace包含可识别的表结构，不能证明当前目标/场景产生了事件、工具能导出可配对的逐帧时间，或该源适合作为Jitter参考。判断时应分别核表schema、事件行、目标/显示身份、时间域与资源门；任一缺失均不准入。该E4观察不能外推为设备普遍不支持，也不确认参考不可用。attempt-04结果与独立复核。
attempt-04观察器墙钟45.059414秒超过45秒硬门；RSS峰低于门，最终Trace大小也低于单独输出字节界，但Trace保存发生在观察器结束后，故不能用最终大小补成完整资源通过。该配置不重试；本次全手机写入归属保持unknown。
截至2026-10-22的历史状态快照为Jitter正式验收0/5。离线合同与审计器通过只属于E2工具验证；当时Metal候选资格尚未判定。
8. 证据与适用范围
截至2026-10-22的历史证据快照：Jitter公式、Registry、Source Contract、实时共享窗口、Frame Report v4摘要及软件边界控制为E2；当时真机正式验收0/5、整体37/66，手机未操作，Metal候选资格未判。Jitter也不是Apple Hitch或硬件级timing variance的官方等价值。
9. 如何分析 Jitter
推荐与 P50 / P95 一起看：
text
P50 正常 + Jitter 高
→ 典型体验正常，但节奏偶发不稳
P50 高 + Jitter 低
→ 整体变慢，但每帧可能仍较均匀
P50 高 + Jitter 高
→ 整体变慢且长尾明显然后再进入 Jank/Stutter 与 CPU/GPU/I/O 同窗分析。
10. 版本历史
| 版本 | 日期 | 修订要点 |
|---|---|---|
| current-display-device-lag-lower.v1 | 2026-10-04 | 同钟过期下界>2s置空/stale-device-source，数值公式不改；22匹配/全量E2与b116安装E3通过，新真机E4未测、54项100%仍partial。G7。 |
| v1（公式不变） | 2026-09-17 | 从 Display 总览拆出独立 Canonical，冻结 10 秒 P95-P50 定义与 P50 算法。 |
| v1 输出链路补记 | 2026-10-03 | 已发布实时值补入最终覆盖与 CSV；公式不变，缺值不补零，新包 E4 待验证。 |
| v1 同窗验收合同 | 2026-10-22 | 明确使用经来源与连续性验证的 P95 同窗样本；补充 Metal 实际呈现时间候选的 0 哨兵和同窗资格门。 |
| v1 共享窗口实现 | 2026-10-22 | 实时 Jitter 复用已验证 P95 样本/质量/新鲜度；Frame Report v4 增加末窗摘要；独立复核补充损坏身份与显示字段 fail-closed。56 项聚焦及 2,874 项 Sidecar 全回归通过，E2；正式五轮仍 0/5，物理精度未校准。见方案与实施记录。 |
| v1 Instruments 候选边界 | 2026-10-22 | 记录 Animation Hitches 可观察帧生命周期与垂直同步但不等价于 Jitter；既有资格探测/trace 导出超出资源门，当前配置拒绝，不得重跑或放宽门槛。见资格调查记录。 |
| v1 Metal 独立参考逐窗合同 | 2026-10-22 | 冻结双钟/唯一匹配、全事件覆盖、Raw 前驱、10秒窗口重算与0.400002ms差值界；离线工具通过不等于参考合格或 Jitter 正式验收。当前正式0/5、物理精度未校准。见参考审计器合同与验证。 |
| v1 Metal 审计实现与分离复核 | 2026-10-22 | 完成带 seal/Raw oracle 前置门的逐窗审计工具、目录句柄 no-follow 输入与连续/绝对时钟 offset 边界独立复算；52项离线合同测试通过。synthetic E2 不证明 Metal 资格、物理精度或五轮验收。见实现记录。 |
| v1 Metal 时钟域修正与正式首轮 | 2026-10-23 | 固定7个物理参考窗首轮7/7合格，Metal与Raw Jitter最大差0.000001ms；179条Raw/Metric/CSV逐点一致。当前正式1/5，整体37/66；全窗候选仍partial(129/141)，不代表物理校准或整项通过。见方案与r1复核。 |
| v1 r4固定Metal参考窗资格复核 | 2026-10-23 | r4固定窗主审计与独立复算6/7；一窗FrameLifetime未与Metal presentedTime配对，长尾阶段方向门失败，r4不计轮次。正式保持3/5、整体37/66，参考不可用未确认。见方案与r4复核。 |
| v1 r4未配对事件与Frame Lifetimes候选 | 2026-10-23 | 独立时钟复算确认未配对事件位于Fixture主线程延迟期、下一drawable提交前；具体FrameLifetime语义未证。Metal r4不计轮次，正式3/5、整体37/66；Frame Lifetimes仪器仍待资源/导出准入，不确认无参考。见诊断与用例。 |
| v1 Frame Lifetimes 进程名 attach 准入诊断 | 2026-10-23 | xctrace --attach <name>在本次真机环境未找到已由DVT观察到的进程，未生成trace；仅拒绝该配置，参考不可用未确认。见attempt-03结果与独立复核。 |
| v1 Frame Lifetimes GUI schema-only trace 准入诊断 | 2026-10-23 | GUI Trace可读出16字段schema但无逐帧事件行；观察器墙钟45.059414秒越过45秒门，配置不准入、不重试。工作台预览保持未清理；Jitter仍3/5、整体37/66，参考不可用未确认。见attempt-04结果与独立复核。 |
| v1 Display c01 设备通道资格诊断 | 2026-10-23 | xctrace收到record-start但约12.1秒后设备通道断开，退出码0未证明40秒Trace完整；Display表导出0行。Fixture唯一run稍后封存且旧证据保持不变；候选不准入、参考不可用未确认。服务占用冲突仅为待证假设，下一attempt关闭直连DVT/AFC后再启动Instruments。见Display冷启动方案与c01复核。 |
| v1 Display c02通道与XML表身份核对 | 2026-10-23 | Fixture封存E4、Trace实际0.343416秒并断连；TOC表序号核对证明两行仅为时钟/显示元数据，逐帧事件0。CoreDevice服务查询后续恢复，录制仍待新准入；正式3/5、整体37/66不变。见c02结果。 |
| v1 Display d01通道短测边界 | 2026-10-23 | 自然2.337262秒结束但连接日志/RSS读取覆盖门失败；空闲屏幕零事件不确认无参考。来源d01结果。 |
| v1 e01及无参考新五轮 | 2026-10-23 | e01有28事件但仅0.331324秒，观察覆盖通过；当前环境无完整独立对照，新无参考五轮0/5。当前参考决策与新五轮合同。 |
两轮旧 Session 的实时样本已有有效 Jitter，但最终覆盖曾误记 missing/0、CSV 漏列。本批修复只持久化已发布、有限且质量有效的样本；上游帧源间隙并未因此消失。
继续阅读：P95 FrameTime · Jank、Stutter 与帧体验。
2026-10-04 · 当前窗的设备时钟过期保护
同一已核Session/目标代际/重连且两源实测Mach timebase一致，lagLowerNs=max(0,sysmontap.EndMach−FrameLifetime.endMach)×numer//denom是过期下界，不是精确年龄。严格超过2s时，本实时Display指标置空、质量stale-device-source；age上界未知继续null。下界小/无钟不是当前新鲜证明，原host-silence、one-shot、warmup与缺值门保持。旧Raw和native历史数值不回填，完整当前窗/独立scope与五轮100%仍待新包验收。
版本历史增量：current-display-device-lag-lower.v1（原数值公式不改），E2同钟/代际/边界及原迟到数据离线对照通过，E4与全54可信目标仍partial。共享时钟定义 · G7实施与证据。
版本增量 · 2026-10-23 · v1新完整五轮正式验收
五个独立新Session固定600/600槽及888条消费者发表数据核同，旧SHA不变，当前E4场景正常性正式通过。标记NO_REFERENCE_ACCEPTED_OWNER_POLICY，完整物理精度仍未校准；旧3/5及r4失败不改。来源。