realtime design

[Tim Daneliuk]

Tim Daneliuk wrote:
> 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.
> 
> 

One last thing: The scenarios and problems outlined above can be avoided if
the simulation in fact simulates *time* itself (I think Mr. Ewing was
hinting at this as I reread his post). In this case, a clock "tick" is
merely a software counter which moves things forward one system quantum. In
such simulations, actual "real" time is not preserved but determinism and
sequencing are. This can be very useful in examining the behavior of a
proposed or existing real world system.

In this case Python absolutely could and would serve nicely as an
implementation vehicle. Some very interesting OO design issues emerged as I
thought about this. What should the central set of objects include, for
example? Clearly hardware events like interrupts need to be represented,
but so does time itself - or at least the behavior of hardware clocks.
'Mighty interesting project indeed...



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