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

Poul-Henning Kamp phk at phk.freebsd.dk
Fri Sep 23 20:45:28 UTC 2011

In message <4E7CDEB0.8070605 at earthlink.net>, Jim Lux writes:

>Actually, the really annoying one is where I have a good clock that's 
>stable, but I need to keep adjusting "time" to match someone else's 
>terrible clock.  Most clock disciplining/time propagation models assume 
>your bad clock is following a better clock.

That is exactly what happens when you put an OCXO or Rb in a computer
and run NTPD against a server across the internet :-)

I still have a hard time drawing a boundary about this next level up,
and maybe I'm misunderstanding you, so let me think out loud for
a moment:

Its pretty obvious that you can build a suitably general mathematical
model that will cover anything you can expect to encounter:

A polynomium of a dozen degrees will catch any PLL-like regulation
pretty well, add a fourier series for periodic terms like your
temperature variations and finally chop it into segments to
correctly deal with discontinuities from power failuers or

But isn't that so general that it becomes meaningless ?

Determining two or three dozen Finagle constants doesn't sound like
anything close to "real-time" to me, and it all hinges crucially
on the mathematical model being expressive enough.

Something like the SOHO unthaw would be a really tough
challenge to model I think.

The opposite approach is accept that clock-modelling is not the
standardized operation, but representing the data to feed into the
clock-modelling software should be a standard format, to facilitet
model reuse.

Some of that data is pretty obvious:
	Time series of clock offset estimates:
		Which other clock
		Uncertainty of other clock
		Measured Offset
		Uncertainty of Measured Offset
	Craft orbital params
		XYZT, model gets to figure out what is nearby ?
		Parametric model (in orbit about, ascending node...)

And then it gets nasty:
	Vehicle Thermal balance model
		a function of:
		Vehicle configuation
		Vehicle orientation
		Nearby objects (sun, planets, moon)

	Clock model:
		a function of:
		vehicle temperature,
		bus voltage
		magnetic fields from craft
		vibration (micrometeorites, think: Hipparcos)
		clock age
		random clock internal events

And the list probably goes on and on, until we come to individual
component failure effects.

Missing in this picture is the organizational boundaries:
The mission data comes from one place, and the clock model
or clock parameters are probably delivered by the manufacturer
of the specific device?

How many of these parameters you need to include will of course
depend on the exact vehicle and mission requirements.  There is a
heck of a difference between a commercial geo-stationary comms
satelite and Gravity Probe B and Gaia.

One can always say "put it in XML and hope for the best" but
that's not much of a standard, is it ?

Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

More information about the time-nuts mailing list