realtime design

[Chris Liechti]

"Bradley D. Larson" <blarson at crary.com> wrote in
news:mailman.1034549538.24177.python-list at python.org: 

> Real-time does not always mean "micro" or nano second response.  The
> granularity is dependent upon the need of the underlying system.

i know. i didn't wanted to imply otherwise. it just that the discussion 
seemed to go in the direction of fast responses...

i would say that a normal OS (Windows, Linux, others) is suitable for real 
time down to the range to 1s timesteps. longer times beeing easy. there's 
of course no guarantee that even that can be met. there much longer delays 
(e.g. accessing the floppy under windows or deleting a large file under 
linux ext2, spinning up a HD from low power when accessed)
if one needs a _guaranteed_ response in the range of seconds or shorter, 
then there is no way around a real time OS (or such a primitive 'thing' - i 
don't want to call that an OS ;) - like DOS)
(i think there are real time extensions in both, Linux and Windows, but 
they're not accessible to user programs. both OS have features for very 
short delays etc. for the use in kernel drivers)

i'm working with a real time system in the 125ms range and it works quite 
good. it runs on machines from 200Mhz Pentiums up to much faster ones.
but it's not critical when one timeslot is not met and uses longer.

what i'm saying is that for hard real time you need a real time OS ("hard" 
meanung that you have time constraints that must be met in _every_ case)
for soft real time a normal OS without special extensions is suitable too 
("soft" means it does not hurt when the constraint is missed once, but held 
in most cases)

the fact that it uses Python or an other languages does not matter all that 
much. some make it easier, some harder. of course, Java with it's gc in the 
background makes predictions how long something takes harder, especialy for 
short times, that's a problem in Jython. CPython is much easier to 
understand with it's reference counting.

> Government Definition:
> 
> real time: 1. The actual time during which a physical process occurs.
> (188) 2. Pertaining to the performance of a computation during the
> actual time that the related physical process occurs, in order that
> results of the computation can be used in guiding the physical
> process. 
> 
> Source: http://www.its.bldrdoc.gov/fs-1037/dir-030/_4450.htm

heh, if we take the second definition, then Python meets the requirements.
we just have to choose an appropriate problem, though ;-)

chris

> Chris Liechti wrote:
> 
>> ... what you need is an underlying realtime OS, that guaratees that
>> the real time tasks get enough CPU power at the right time. without
>> that absolutely no programming language can help out.

-- 
Chris <cliechti at gmx.net>