realtime design

[Tim Daneliuk]

Greg Ewing wrote:
> Bengt Richter wrote:
> 
>> It sounds a bit funny to me to be worrying about "too long" (presumably
>> _real_ time?) in a realtime *simulator* (especially after saying 
>> performance
>> is no issue). I guess you're not simulating time itself in your 
>> realtime simulator?
> 
> 
> 
> I've been wondering about that, too. If you're seriously
> trying to simulate the behaviour of a real-time system,
> you want the timeout to occur after a certain amount of
> *simulated* time, not actual time. To be able to do that,
> your simulator needs to have a notion of how much
> simulated time each operation takes, and keep track
> of it.
> 
> So, before going any further, the question which must
> be answered is: how accurately does the behaviour of
> the simulated system in simulated time have to reflect
> the behaviour of the real system in real time?
> 

All that is true, but the problem here is not absolute time response but
*determinism*. If I understand the commentary above (and I may well not!)
the issue is that you cannot get predictable (== deterministic) behavior
when python hands control down to a lower layer of code written in 'C'.

IMHO, this has much less to do with the way the code is implemented in 'C'
and more to do with the fact that the underlying *system* (unix, win32,
macos) is not deterministic. For example, if the C function invoked happens
to do some disk I/O you will get rather large variations in response times
depending on how busy the VM system and disk I/O subsystem are. This has
little to do with C and everything to do with the aforementioned
subsystems.

Similarly, and having nothing to do with 'C' code, the simulation itself
will have variable timing even if written in pure Python simply because
housekeeping like garbage collection can influence the 'realtime'
determinism of the system.


-- 
------------------------------------------------------------------------------
Tim Daneliuk
tundra at tundraware.com