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

[Magnus Danielson]

On 24/09/11 00:13, Jim Lux wrote:
> On 9/23/11 2:00 PM, Chris Howard wrote:
>>
>> Seems like a lot of unknowns. You would have to
>> have sensors monitoring the sensors.
>
> I think the "clock model" (insofar as variations in the oscillator) are
> outside the scope, as long as the effect of that variation can be
> represented cleanly.
>
> For example, with a simple 2 term linear model t = clock/rate + offset,
> you can describe the *effect* of a rate, and if the rate changes, the
> model changes. As long as you keep track of the rates and offsets you've
> used in the past, you can reconstruct what "clock" was for any t or vice
> versa.

Which is more or less what calibration records is about.

Infact, how all these measures are intended to be used to provide a 
corrected measure with uncertainty bounds is not very well covered in 
the papers. It's scattered around.

As for the model at hand... the optimum 2-term model and its update log 
might not provide best performance with parameteres directly 
interchangeable with the optimum 3-term model. That being said, meaning 
that the phase error, frequency and drift does not provide a good source 
for phase error and frequency and vice versa.

You might consider to standardise the models in order to provide the 
quality in interchange of measurements. You might require to have 
support for several models and essentially provide a frame-work standard 
for transporting model data. Interconnecting models might need 
additional tought.

I need to think about that one.

> A clock model predictor might use all those factors to better estimate
> the rate. Having a high order polynomial model might let you not need to
> update the model parameters as often. That's a tradeoff the user could
> make: Do I use a 2 or 3 term clock to time transformation, and update it
> once a minute, or do I use a 20 term transformation, and update it once
> a month.

A 20 term model requires fairly high precision and good rate 
measurements to become meaningfull. Irregular updates as such is not a 
problem, as long as you can induce precission into the system when needed.

> OK, so if you wanted an output from your Time API that gave you a
> "estimated uncertainty of time" (think like the accuracy estimates from
> GPS receivers), what would that look like?

Estimated parameters:
timeoffset, frequencyoffset, driftoffset

Uncertainty matrix

Just look in the manual of a better GPS and you essentially see the 
Kalman filter model and its parameters popping out.

> Do you give a 1 sigma number? What about bounding values? (e.g. the API
> returns "the time is 12:21:03.6315, standard deviation of 1.5
> millisecond, but guaranteed in the range 12:21:03 to 12:21:04)

You do not want bounding values, noise forms makes it hard. one-sigma 
values help. In all this, I keep thinking Kalman filter (or the like).

If you want a standard way of present numbers, you will have to build 
that ontop on standard models.

It would be interesting to see what a combination of mutual 
synchronisation within a constellation and central synchronisation would 
yield. Your constellation would maintain contact with each other and 
pull eachother to some form of average time (according to arbitrary 
time-scale) and then use the earth link to provide long term 
corrections. A good mutual synchronisation strategy would allow the 
constellation to shrink and grow without falling completely appart.

If you provide ranging mechanisms within the constellation path delays 
can naturally be compensated out of time.

> I would expect that a fancy implementation might return different
> uncertainties for different times in the future (e.g. I might say that I
> can schedule something with an accuracy of 1 millisecond in the next 10
> minutes, but only within 30 milliseconds when it's 24 hours away)

This is true, but if you need higher certainty at a particular time you 
can schedule a synchronisation event or two where uncertainties can be 
reduced. If you have the Kalman state and state-vector, you can run the 
predictor into the future.

> The mechanics of how one might come up with this uncertainty estimate
> are out of scope, but the semantics and format of how one reports it are
> in scope for the architecture.

I think you will need to look at the clock models being used. It may be 
that the models all belong to Kalman types, but with different model 
sizes... but then someone needs a particle filter model... what if the 
IMU model is used... time and position.

At least a survey over feasable models needs to be done to see what can 
be done.

Cheers,
Magnus