>From devel/packaging.txt Two instances talking to each other have no way to know that they're based in the same era. To mitigate this problem, each instance has a pivot date and resolves incoming timestamps to the era that minimizes distance between now and the timestamp. This procedure is part of the core protocol specification.
[Minimum distance could be negative and large enough to be before the build date.] >From blog/_drafts/gps-pivot.ad The GPS system has a cyclic clock with a 1024-week period. Each device has a cyclic clock with the same period, but it can only disambiguate over exactly a half cycle in either direction from its hidden pivot date. once a gps gets half of a 1024 week span past its pivot, it fails, emits wrong dates wrong by modulo 10 bits of weeks --------- The above is a possible solution, but it's not what I was expecting. The above description with "half" in it works if you put the pivot point in the middle of the target range. You can also put the pivot at the start. Then legal values are from the pivot point until pivot + one cycle time. It's signed vs unsigned values. We are using the build date for the pivot point. That works naturally as a start time rather than middle time. (It's possible I've missed some code that bumps the build date by a half-cycle. I wasn't expecting it so I wasn't looking for it. But that also means that I would be surprised and pay attention if I did see something like that.) -- These are my opinions. I hate spam. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
