--001636c5c042f8d95b048a5c0776
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jul 1, 2010 at 3:10 PM, Chuck Remes <cremes.devlist / mac.com> wrote:

> The entire system is akin to a distributed state machine. I poke a command
> into it from the outside and it sets off a cascade of events which in turn
> generate more events until eventually I have my answer. Some the events have
> timeouts or other time-based characteristics associated with them. Also,
> some of the returned data has time-based characteristics (e.g. a timestamp)
> which impacts the transitioning of the state machine. It's all working quite
> nicely in real-time.
>
> My problem is mocking out the time source so that I can run simulations in
> faster than real-time. For example, I may send a request for a data record
> and give it a 5 second timeout. This works fine when the clock source is the
> actual operating system, but if I want to run faster than real-time I need
> to mock the clock out. That is, I want to take a simulation that might run
> in 4 hours real-time (with lots of waiting or other timer related delays) to
> run in 20 minutes because 1 second of simulation time is only a fraction of
> a second in the real world.


It sounds like the way you've written your program is time-dependent, or as
ChucK (the music language) would describe it "strongly timed"

Right off the bat my initial advice would be to eliminate the need for a
central clock in your system and make it fully asynchronous.  Creating
"strongly timed" synchronized distributed systems is rather non-trivial.

-- 
Tony Arcieri
Medioh! A Kudelski Brand

--001636c5c042f8d95b048a5c0776--