Running in Simulation Time

Hi Dan, can you explain a bit about how the simulated time domain is achieved? Are the clocks built into your OS set to run at a slower rate somehow?

I'll explain a bit about how I imagine this would work, and I'll use Linux as an example platform because this is the one I'm most familiar with. In Linux, there are a number of different clocks, e.g. CLOCK_REALTIME, CLOCK_MONOTONIC, etc. They're all documented in the man pages. 

At the end of the day, Connext uses system calls (POSIX calls) to get the time from your OS. Connext uses these clocks built into the OS for a variety of reasons, e.g. to timestamp samples, keep track of periodic events, etc. There are actually two distinct clocks in our product, the internal_clock and external_clock, and they can each be configured to use different OS clocks as their source. The purpose of these two clocks is documented here. To summarize, Connext's internal_clock is used for the timing of internal events within the middleware, e.g. keeping track of liveliness, reliability, so forth. The external_clock is used to assign timestamps to samples.

For example, you could configure internal_clock = monotonic, so that the Connext internal_clock uses CLOCK_MONOTONIC as its source. You could just as easily configure internal_clock = realtime if you wanted it to use CLOCK_REALTIME instead. In general, for Connext applications where the computer is using NTP or there could be jumps in system time, we require you use internal_clock=monotonic for correct operation. In this way, Connext's internal events will still fire at the correct time because the monotonic clock isn't affected by system time changes caused by NTP (or even manual changes to the clock). The article linked above explains this in more detail.

So, returning to your question now... In principle, in order for Connext to operate in the same simulation time domain, then somehow the simulation time domain needs to be slowing down the rate of the OS clocks (e.g. CLOCK_REALTIME, CLOCK_MONOTONIC, etc.). Remember, Connext just gets the time from POSIX calls, which rely on your OS clocks. If these OS clocks are operating correctly, just at a slower rate than real-time, Connext should operate successfully in this time domain. We will need to test things out to make sure they're working the way we expect, but this is my initial take on your question. On the other hand, if the simulated time domain is somehow independent of the OS clock, i.e. the OS clock is still running in real-time, then Connext will simply be using the OS clock and won't be operating in this simulated time domain.

If you'd like, we can schedule a call to continue discussing this.

Best,

Grayson

RTI | Software Engineer

Hi again Dan, digging around a bit online, I found one possible solution for you. See here. I'll copy paste the answer below for posterity:

You can use the LD_PRELOAD trick described in this question.
Libfaketime seams to do exactly what you need (see the README under "Advanced time specification options"). The following example shows time going 2x slower for "sleep":

$ time FAKETIME="x0.5" LD_PRELOAD=/usr/lib/x86_64-linux-gnu/faketime/libfaketime.so.1 sleep 1
real    0m2.002s
user    0m0.000s
sys 0m0.000s

(on a debian system, therefore /usr/lib/)

If it doesn't actually do what you want, instead of rolling out your own solution, I'd suggest taking its source and implementing what you need from there.

For completeness' sake, another possible starting point is datefudge.

So this is a pretty interesting option. The libfaketime implements the standard POSIX calls related to time, and it provides a way to scale time up and down. With the LD_PRELOAD trick, you can use this to intercept/override your OS's clock POSIX calls with the libfaketime implementations. This interception means Connext would be getting its source of time from libfaketime and seeing the "scaled" version of time you might want.