[time-nuts] seeking a time/clock software architecture

[kevin-usenet at horizon.com]

The issue here is one of data compression.

On-line clock sync algorithms (like NTP) typically use a very simple
piecewise linear mapping function, but update it very frequently, up
to once per second.  Phase is continuous, and steps in rate are small
enough not to be a problem.

This is great if you only need to translate current (or very recent)
timestamps, and don't care about the mapping function more than a
minute ago.


On the other hand, the most off-line clock sync algorithms, like
those relating to UT2, use dozens of non-linear terms to enable
a fit that lasts for years or decades.

This makes the translation of any one timestamp much more difficult,
but makes storing the mapping function much more difficult.


It's a classic space/time tradeoff, like the difference between a formula
and precomputed tables.


The question to be decided here is, what sort of mapping function
do you want?

One possibility, and you must decide if this is acceptable, is to
use a simple piecewise linear function in the short term, but then
compress that with a higher-order fit for storage.

This has the downside that the compression is lossy; the compressed
mapping function will compute a different answer than the original
piecewise linear one.  But you can choose your compression implementation
to bound that error.