[time-nuts] FreeBSD, NetBSD, or Minix-III?

[Lux, James P]

On 5/24/09 11:13 AM, "Hal Murray" <hmurray at megapathdsl.net> wrote:

> 
> 
>> Also, someone I was discussing this with at work reminded me of a
>> common problem.  We often run tests in a testbed where we need to have
>> the entire testbed running at some time *not the actual time*.. E.g.
>> If you're simulating a Mars entry,descent,landing scenario, you want
>> the spacecraft running with "time" at the expected EDL time.  But, you
>> want to have everybody sync'd to a common source.
> 
>> So, it's easy to get all the computers controlling the test gear
>> sync'd to UTC or TAI using something like NTP, but you need a way to
>> have precision "simulated time" as well.
> 
> Is the "entire testbed" isolated from the rest of the network?  (If not, what
> do you do about the time warp?)
Unfortunately not.. And you have the annoying thing of modern test
instruments that run, e.g. Windows Embedded, and have internal clocks, so
when you capture a measurement, the file date/time is the system date/time.

In the long run, I think it's easier to keep everything on one time base
(e.g. TAI/UTC), and fight the downstream battles to turn "observed time"
into simulated time.

But it gets tricky with things that use timecode (IRIG-B, for instance) and
send 1553 messages.

I don't think there is a universally "good" solution, in any case.

> 
> Just setup a ntpd running with the local clock (127.127.1.0).  Set the time
> manually and point all of your other boxes at it.  Details TBD.  You will
> probably have to restart ntpd since they won't jump more than 1000 seconds
> once it is running.

And, there's the problem of keeping things straight between the "local time"
and "global time".


> 
> It local-server box keep (much) better time if you let it run normally for a
> while to calibrate the drift factor.
>