Why declare clock models instead of inferring offsets, and what breaks if the anchor is wrong? #1
|
The clock alignment module takes explicit offset/skew/anchor per source rather than inferring them from the data. I understand the honesty argument, but mechanically: how much does a wrong anchor actually cost, and when does anchor choice stop mattering? |
Replies: 1 comment
|
The anchor matters exactly in proportion to skew - which is the cleanest way to reason about it.
The practical rule: put the anchor at the most trustworthy instant you actually have for that source (a sync point), not at the start of the window. A sync point late in the window keeps both the offset and the inferred drift small near the events you care about. |
The anchor matters exactly in proportion to skew - which is the cleanest way to reason about it.
The map is affine:
reference = raw + offset + skew * (raw - anchor). Read it as: at the anchor instant, the correction is exactlyoffset; away from the anchor,skewadds a term that grows with the distance from the anchor. So the anchor is the point where your stated offset is pure.Wrong anchor, zero skew: harmless. If
skew = 0the anchor term vanishes and only the constant offset shifts the timeline - you can move the anchor anywhere and nothing changes. That is why anchor choice only shows up in sources with measurable rate error.Wrong anchor, nonzero skew: a tilt. Mis-stating the an…