[time-nuts] seeking a time/clock software architecture
magnus at rubidium.dyndns.org
Sat Sep 24 23:31:42 UTC 2011
On 24/09/11 15:12, Jim Lux wrote:
> On 9/24/11 1:58 AM, Magnus Danielson wrote:
>> 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.
> Precisely so. I figure the whole "synchronization/syntonization of an
> ensemble of clocks of varying quality with aperiod updates" has probably
> been addressed in the literature in some way.
It has. I can dig up some references for you.
The trivial essentially pulls the clocks towards each other. The more
complex will include weighing. This problem has been beaten to death.
NIST has made a line of publications on their A1 atomic scale and
algorithms for it, including code actually.
Mutual synchronisation has also been investigated in telecom situations.
Essentially, if two clocks steer against each other they will lock
half-wise. Common mode changes will still affect them but diffrential
mode changes (including noise) will become somewhat reduced.
>>> 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.
> That is what I was thinking.
That would be fairly trivial.
We should discuss filter models then.
More information about the time-nuts