A
Armin Steinhoff
(Originally posted Thu 07/09/1998)
At 09:55 08.07.98 +0100, Mike Granby wrote:
>> "What is the exact definition of real-time [applications]?"
>
[ clip ..]
>
>> HARDWARE
>> [1] supports at least one interrupt level
>> [2] CPU reacts to interrupts
>> [3] CPU supports context switching
>
>I agree about [1] and [2], but then again these are hardly onerous
>requirements. As for the CPU supporting context switching, if this means
>via hardware (ie. a single instruction to swap the entire execution
>context) then you're knocking-out many self-proclaimed RTOS's that run
>on processors that do not support this sort of thing.
Yes ... this criterion is too hard.
>If you mean via software, then virtually any processor is capable of doing
this via
>stack operations.
>
>> SOFTWARE
>> [1] event driven management of system resources
>> [2] deterministic response times to events with a predictable jitter
>> [3] deadlines for the processing of events are met with a predictable
>> jitter
>> [4] supports priority levels for task processing
>> [5] supports fast context switching of tasks
>
>I don't understand "management of system resources" in [1],
System resources are CPU time, shared resources like memory or IOs ...
which are assigned to processes by external events (also time events) ...
so e.g. the CPU is assigned based on external events ... priority driven.
>so I cannot comment further on that issue. Point [2] requires
deterministic >response
>times to events, but these responses can only be determined in the
>context of the application, as the processor can only do one thing at
>once. This is thus a property of the application / OS system and not of
>the OS itself. The same surely applies to point [3]. I accept point [4]
>without argument, while point [5] is quantitative in nature and thus not
>a useful part of a solid definition.
It is an important technology attribute ....
>The million dollar question: Is WinNT an RTOS under this definition?
>
>> HARD REAL-TIME SYSTEMS
>
>I won't go into these in detail, as most as just tighter version of the
>above, although I accept that there are also some unique properties not
>included in the non-hard RT definition. Overall, though, I am still left
>with the feeling that most of the supposed properties of an RTOS fall
>into two categories...
>
>1/ Those properties which are defined in a quantitative way. For
>example, an RTOS must meet such-and-such a context switching time, and
>must be able to scheduling tasks with an accuracy of so-many
>milliseconds. These values of properties are self-evidently defined by
>the application in question, and so to my mind cannot form part of a
>definition. While you or I might be happy with responses in
>milliseconds, some people will need them in microseconds, and some
>people might be happy to wait a second or two.
The response time is only an important technology parameter which helps to
meet deadlines. E.g. with a response time to events (processing start) with
a variation of milliseconds ... you can't meet deadlines (processing end)
with a variation in the range of 100us.
>2/ Those properties which are easy to define in a simple system, but
>which in a real application are determined just as much by the
>application context than by the OS. For example, it has been said that
>an RTOS must be able to guarantee that a task can be run by a given
>deadline. And yet the RTOS cannot do that if the application has a
>higher priority task running at that point. In other words, the response
>of the system to the real world is determined as much by the application
>as by the OS.
This shows how important it is that "the management of system resources" is
event driven !
The application can hold the CPU only for a defined 'time slice' ... and
will then be preempted by the scheduler . The rest has to be defined by
the task design of the whole software system.
Armin Steinhoff
http://www.DACHS.net
At 09:55 08.07.98 +0100, Mike Granby wrote:
>> "What is the exact definition of real-time [applications]?"
>
[ clip ..]
>
>> HARDWARE
>> [1] supports at least one interrupt level
>> [2] CPU reacts to interrupts
>> [3] CPU supports context switching
>
>I agree about [1] and [2], but then again these are hardly onerous
>requirements. As for the CPU supporting context switching, if this means
>via hardware (ie. a single instruction to swap the entire execution
>context) then you're knocking-out many self-proclaimed RTOS's that run
>on processors that do not support this sort of thing.
Yes ... this criterion is too hard.
>If you mean via software, then virtually any processor is capable of doing
this via
>stack operations.
>
>> SOFTWARE
>> [1] event driven management of system resources
>> [2] deterministic response times to events with a predictable jitter
>> [3] deadlines for the processing of events are met with a predictable
>> jitter
>> [4] supports priority levels for task processing
>> [5] supports fast context switching of tasks
>
>I don't understand "management of system resources" in [1],
System resources are CPU time, shared resources like memory or IOs ...
which are assigned to processes by external events (also time events) ...
so e.g. the CPU is assigned based on external events ... priority driven.
>so I cannot comment further on that issue. Point [2] requires
deterministic >response
>times to events, but these responses can only be determined in the
>context of the application, as the processor can only do one thing at
>once. This is thus a property of the application / OS system and not of
>the OS itself. The same surely applies to point [3]. I accept point [4]
>without argument, while point [5] is quantitative in nature and thus not
>a useful part of a solid definition.
It is an important technology attribute ....
>The million dollar question: Is WinNT an RTOS under this definition?
>
>> HARD REAL-TIME SYSTEMS
>
>I won't go into these in detail, as most as just tighter version of the
>above, although I accept that there are also some unique properties not
>included in the non-hard RT definition. Overall, though, I am still left
>with the feeling that most of the supposed properties of an RTOS fall
>into two categories...
>
>1/ Those properties which are defined in a quantitative way. For
>example, an RTOS must meet such-and-such a context switching time, and
>must be able to scheduling tasks with an accuracy of so-many
>milliseconds. These values of properties are self-evidently defined by
>the application in question, and so to my mind cannot form part of a
>definition. While you or I might be happy with responses in
>milliseconds, some people will need them in microseconds, and some
>people might be happy to wait a second or two.
The response time is only an important technology parameter which helps to
meet deadlines. E.g. with a response time to events (processing start) with
a variation of milliseconds ... you can't meet deadlines (processing end)
with a variation in the range of 100us.
>2/ Those properties which are easy to define in a simple system, but
>which in a real application are determined just as much by the
>application context than by the OS. For example, it has been said that
>an RTOS must be able to guarantee that a task can be run by a given
>deadline. And yet the RTOS cannot do that if the application has a
>higher priority task running at that point. In other words, the response
>of the system to the real world is determined as much by the application
>as by the OS.
This shows how important it is that "the management of system resources" is
event driven !
The application can hold the CPU only for a defined 'time slice' ... and
will then be preempted by the scheduler . The rest has to be defined by
the task design of the whole software system.
Armin Steinhoff
http://www.DACHS.net