Control.com - Nerds in Control

(Originally posted Tue 05/26/1998)
Here is the situation:
I am currently studying hard-real time extensions for Windows NT. One of the problem of NT with real-time is that the system uses CLI/STI (CLear Interrupt/SeT Interrupt). In principle, these operations are used only in the HAL and in the drivers... Theorically, by rewriting the HAL and choosing well-written drivers (hard stuff?) you can expect good performances from NT...
Here is my question:
But somebody say me that the kernel itself use hard-coded CLI/STI. As the kernel cannot be modified, this definitively prevent hard real-time under NT.
Can anybody confirm or invalidate this affirmation?
Antoine PERRIN
CJ-international

(Originally posted Wed 05/27/1998)
Why does the existence of sections of non-interruptible code prevent “real time” operation, assuming of course that those pieces of code are small and deterministic?

Mike Granby
Paradigm Controls Limited
http://www.paracon.demon.co.uk

(Originally posted Wed 05/27/1998)
Mike, your question is a good one. Of course interrupt response code must be small and deterministic. One of the primary problems in our definition of “hard” vs. “soft” real-time is not the architecture of Windows NT. It can only do so much with the 4 hardware levels built into the Intel x86 architecture. The compromise is that all device interrupts are handled at the same hardware level with tight small code to note the system clock at the time of the interrupt, queue a task for processing and to branch out of interrupt mode. I think Microsoft does the best it can with the kernel and HAL routines as it can with the Intel architecture. Anyone that builds on the HAL must keep the idea in mind that processing interrupts should be done in the same way that MS does it - quickly and queue a task for later execution at the background interrupt level.
Dick Caro
Richard H. Caro, Vice President
Automation Research Corporation

(Originally posted Wed 05/27/1998)
Dick these are good points. I think I understand most of it. I do not
proclaim to be a hardware expert. However I can setup a mean DOS or Windows
3.x machine <G>
My question(s). How does the Alpha or PowerPC compare? What about Merced?
And does anyone know if there Real-time extensions for Windows NT that will operate on an Alpha? I guess I need to do some more digging.

Dale Ross
Mitsubishi Electric Automation

Microsoft BackOffice MVP

(Originally Fri05/29/1998)
In general, the RISC machines differ from the Intel x86 architecture by offering smaller faster instructions, uniformly sized instructions, and lots of unallocated registers. This is true of PowerPC, Alpha, Sparc, MIPS and the HP-PA processor which is the basis of Merced. They also offer interleaving of instructions and multistaged pipeline execution and much faster floating point algorithms, but these are at the core of Pentium II and Merced as well. To my knowledge, no RISC chip offers any real-time interrupt features, however, when there are lots of registers, it can be used to “emulate” the action of a real-time architecture. The Intel architecture requires that the interrupt save context (register contents and stack pointers) to MEMORY on interrupt and restore them from MEMORY on return from interrupt. A real-time computer like the ModComp Classic had 16 interrupt levels with 16 registers for each level, one of which was the stack pointer; it did not need to save anything to respond to an interrupt.
The WinNT HAL serves to allow other CPU architectures to emulate the x86 architecture. This is why the 733 MHz Alpha running WinNT works like a 4-500 MHz Pentium. When running DEC UNIX it works like a 733 MHz UNIX machine.
Dick Caro
Richard H. Caro, Vice President
Automation Research Corporation

(Originally posted Thu 05/28/1998)
I agree with all of this. My question, though, was aimed at the original poster who seemed to be claiming that the existence of STI-CLI pairs within the kernel made necessarily NT unsuitable for real time applications.

Mike Granby
Paradigm Controls Limited
http://www.paracon.demon.co.uk

(Originally posted Mon 06/01/1998)
Dear Mr. Caro,

Would you like to share your definition of ‘hard’/’soft’ RT OS with the list?
(Your ‘hard’ sounds to me like ‘hardware’. Is it correct?
If so, what about the QNX community?)
Many Thanks,
Vladimir E. Zyubin
mailto:zyubin@iae.nsk.su
Institute of Automation & Electrometry
Novosibirsk Russia

(Originally posted Wed 06/03/1998)
To refine my earlier message on hard vs. soft O/S—First of all, <<real-time>> has a relative definition: if it’s fast enough for the application, it’s real time. This is why real-time for temperature control may be 4-10 seconds, while flow control is 100-300 milliseconds, and nuclear flux control is 2-3 milliseconds. Part of my background has included real-time computers like the Modcomp Classic, DEC PDP-11, and Foxboro FOX/1 and 1A. These computers made interrupt response very fast via HARDware assistance. All popular microprocessors do NOT have specific hardware support for external interrupts other than the system clock, system faults, and DMA types of I/O. All external interrupts and switching of task threads occurs under SOFTware control. To me, HARD real-time must have some hardware assist, as opposed to SOFT real-time that does NOT. So we have the types of trivial arguments like how many angels can sit on the head of a pin, or does hard real-time require a software modification to the WinNT HAL? All software emulations of hardware interrupt and task switching are SOFT real-time. The only question is how good (time efficient) is the emulation of hardware.
The Intel x86 architecure cannot be made to provide HARD real-time, it does not have enough registers or interrupt levels. It’s all soft real-time, although it may be fast enough for a given application. Use of a RISC engine may offer some hardware support for real-time by allocation of its many registers to interrupt levels. RISC also allows better emulation of interrupt levels than the current CISC microprocessor architectures. To my knowledge, there is only one commercial application of RISC to real-time computing which is from Modcomp that sells a VME microcomputer called REAL/STAR using Motorola 88110 RISC microprocessors and their own port of UNIX called REAL/IX. I would take comfort in calling a REAL/STAR computer running REAL/IX a <<HARD>> real-time system.
QNX was written with their own kernel designed for the best real-time that could be supported on the Intel x86 architecture. It is still, IMHO, a soft real-time O/S, but a lot closer to industrial automation requirements than AT&T UNIX on Pentium. By the way, please note that AT&T UNIX was written for telecom applications which often require true real-time response as well. Not much was included in the UNIX O/S since it was written for the PDP-11 which had 16 levels of hardware supported priority interrupt. UNIX didn’t need soft real-time on this computer since that form of task switching was handled in hardware.
Dick Caro
Richard H. Caro, Vice President
Automation Research Corporation

(Originally posted Thu 06/11/1998)
Dear members,

Firstly, I must apologize for my attempt to discuss the eternal question - what does ‘real-time’ mean.
Secondly, many thanks to Mr. Caro and other members for their definitions of RT. The definitions considerably improve my private collection of the ones.
So, I have a couple of questions to the List members:
1. What is the practical value of the term? (with technical viewpoint, please ;-)
2. Is there anybody who interpret the term (when it appears in a technical article) as ‘mauvais ton’?
3. How many professionals are ready or think of to throw out the term from the vocabulary?
Many thanks in advance...
With kind regards,

Vladimir E. Zyubin
Institute of Automation & Electrometry
Novosibirsk Russia

P.S. I hope the List members forgive me for the heretical thought:
In any text that does not contain a definition of RT, the term can be painlessly replaced by ‘cool’ (for OSes) and by ‘ ‘ (for control systems) :-)

(Originally posted Mon 06/22/1998)
(I realize that Mr. Zyubin wrote this with tongue in cheek, so I will respond in kind.)
For centuries people have recognized that if you cannot speak precisely about a topic, you cannot think precisely about it.
If all you know about gravity is “Things fall down” and if you think the terms “mass” and “force” are some pointy-headed intellectual’s way of trying to make himself seem superior to you and all you need to know is that “some things weigh more,” then there are limits to how well you can perform certain kinds of work—limits, perhaps, that you never encounter in your particular career.
Newton widened the scale of things we could do when he characterized gravity more precisely as a force; Einstein et al. widened the scale far more when they characterized gravity as curvature in space-time; now people are seeking to make the biggest expansion yet—to smaller as well as larger scale— by characterizing gravity in a quantum mechanical way.
This analogy is poor in the sense that only a relatively few of us have improved our professional capabilities with these increasing improvements in perception and understanding of gravity.
But for many of us on this list and elsewhere, the more accurately we understand and can speak about real-time computing—e.g., “hard,” “soft,” “predictability,” “determinism” are especially common examples of dangerous misunderstandings—the better we can meet the needs of those systems and applications which have requirements for acceptable predictability of satisfying timeliness constraints. It’s not (usually) sophistry—it’s mission- and often life-critical in automation systems of significant complexity (that’s a growing percentage of them).
Let’s not flaunt ignorance as a badge of masculinity, and let’s not throw the baby out with the bath water as Mr. Zyubin facetiously suggests.
I have placed the first draft of a new presentation about this on my web site for those who care to join me in seeking to better understand and perform real-time computing for control systems.
Doug
E. Douglas Jensen, at home
jensen@real-time.org
http://www.realtime-os.com

(Originally posted Thu 06/25/1998)
Dear Colleagues,
In despite of the kindly possibility to look like joker, I ought to confess:
It was not a joke.
Here are facts and opinions (according to my experience):
1. The probability that a man speaking “real time” can not “denotate” the term, is about 90%.
2. Frequently, the speakers do not separate two absolutely different weakly-connected things: operating system(OS) and control system(CS).
3. There are three definitions of the term at least (I personally prefer Mr.Jensen’s one). But all of them are too verbose to be precise (again, IMO).
4. If somebody says without a context: “real time system”, the term do not bear any valuable information.
5. In overwhelming majority of the cases, “RT OS” means just that there is a mechanism for a multitasking model of parallelism in order to provide functionality of control algorithm (e.g., corporative multitasking, preemptive multitasking, etc.). I.e., value of the term is pour.
6. “RT CS” - Is there anybody who can suggest an utilization of a control system that can not meet the requirements of the task? I.e., it sounds like a tautology.
7. There is no standard which contains a definition of the term.
8. Plus: Under these circumstances it is quite possible to speak about both OS and CS without utilization of the term. (that I, painlessly for professional conversation, am doing during several years.)

Note: I do not try to state that the term should be avoided, but, IMO, there are a lot of reasons to be careful with the term.
To make the things more clear:
I specialize in predictable deterministic stand-alone control systems with soft multithreading parallelism.
predictable - having possibility to find
maximal time of response to external evident a priory.
deterministic - the maximal time of response is not
probabilistic.
stand-alone - without OS or independent from OS.
multithreading parallelism - a model of parallelism opposite to
multitasking one, parallelism within one task closed to so-called round robin style.
soft parallelism - an opposite to CSP (Communicating Sequential
Processes) model of parallelism, characterized by lack of child-parent connections between the parallel chunks.
With best regards,

Vladimir E. Zyubin
mailto:zyubin@iae.nsk.su
Institute of Automation & Electrometry
Novosibirsk Russia

(Originally posted Mon 06/29/1998)
Dear Colleagues,

I received a message with interesting comments on the topic.
The original message with my replies on it is below. Perhaps, somebody have additional pro or contra. Your comments would be interesting to me... Especially about the “Pseudo Real Time Control System”.
Are there non-hypothetical control systems, where we have to distinguish the following:
&#61623; “20 control cycles per minute”;
&#61623; “1200 control cycles per hour”;
&#61623; “1 control cycle per 3 sec”?

(the strings marked by “>>>” and “>” are mine)

<snip>
>But, IMO, several remarks could be made...

You wrote:<
>>>6. “RT CS” - Is there anybody who can suggest an utilization
of a control system that can not meet the requirements of
the task? I.e., it sounds like a tautology.<<<

>>A Control System is not inherently Real Time. A traffic
light control system would be an example. You might want to
call this a “Sequential Time” Control system. What is
important is that one light turn red before the other light
turns green. What happens if you miss a control cycle? The
driver at the red light gets mad for waiting too long, but
that is it.<<

>Alas, I did not deal with traffic light
control systems, but... It seems to me that there are
timeline requirements in our case as well. I think the
response time is about 1 sec. (If we keep in mind that
source of the input is a timer).<

>>Another case may be a Pseudo Real Time Control System. In
this case you may miss a few deadlines (as long as you do
not miss too many) and the consequences are not too great..
For example you may have 30 control cycles per minute
scheduled but only 28 are executed. The consequence may be
that the cost of your product is $9.02 per unit as compared
to $9.0195 per unit. If you produce 20,000 units per hour
then this would cost you $10 per hour. Of course for this
hypothetical control system, your whole production line may
shut down if the number of control cycles dips below 20
cycles per minute. Now, your company loses big dollars as
well as possible safety concerns.<<

>IMO, a trick is included into “30 control cycles per
minute”... It can be easily reduced to 1 control cycle per 2 sec.
So, in our case the threshold time requirement is 3 sec (1 control
cycle per 3 sec (20 control cycles per minute)), isn’t it?<

>>I agree that in the world in general that there would not be
a consensus on what real time is. However, because of this
forum, I think there is a greater degree of consensus on what
real time is. It has been awhile since I have been to the
Jenson Website; but I do like his definition (i.e. a real
time system must meet its deadlines whether those deadlines
are milliseconds or days).<<

>I agree... if the “a real time system” means
“a control system”. For “OS” it is not the case.<

Thanks,

Vladimir E. Zyubin
mailto:zyubin@iae.nsk.su
Institute of Automation & Electrometry
Novosibirsk Russia

(Originally posted Mon 06/29/1998)
Sometimes things strike you and you feel you have to say something, I got struck by this:

>>Another case may be a Pseudo Real Time Control System. In this case you may miss a few deadlines (as long as you do
not miss too many) and the consequences are not too great..
> For example you may have 30 control cycles per minute
> scheduled but only 28 are executed. The consequence may be
> that the cost of your product is $9.02 per unit as compared
> to $9.0195 per unit. If you produce 20,000 units per hour
> then this would cost you $10 per hour. Of course for this
> hypothetical control system, your whole production line may
> shut down if the number of control cycles dips below 20
> cycles per minute. Now, your company loses big dollars as
> well as possible safety concerns.<<

> >IMO, a trick is included into “30 control cycles per
> minute”... It can be easily reduced to 1 control cycle per 2 sec.
> So, in our case the threshold time requirement is 3 sec (1 control
> cycle per 3 sec (20 control cycles per minute)), isn’t it?<

I wouldn’t be hasty in reducing 30 cycles per minute down to 1 cycle in 2 seconds. Suppose I have an operation (A) which requires, say, 20 seconds, holding up the remaining processing, but once completed, frees the system to do 30 cycles of (B) operation in the remaining 40 seconds? My net throughput is 30/minute, but my processing cycles (B) are running at (rate of) 45/minute for the remaining 40 seconds. I could probably describe the system using either number, depending upon my audience.

And on real-time:

> >>I agree that in the world in general that there would not be
> a consensus on what real time is. However, because of this
> forum, I think there is a greater degree of consensus on what
> real time is. It has been awhile since I have been to the
> Jenson Website; but I do like his definition (i.e. a real
> time system must meet its deadlines whether those deadlines
> are milliseconds or days).<<

I don’t recall if I got this from Jensen, but I’ve heard/read (pardon the paraphrase):
“A real-time system is one in which the timeliness of the data/response is as important as the accuracy for it to be correct.”
Also:
Use of an RTOS (real-time operating system) does not imply creation of a real-time system.
In any case, fast response is not necessarily real-time response, nor does it necessarily guarantee it: I may not want my results right away, but an hour from now, give or take 2 milliseconds. If I can’t get it in that window, the real-time nature of my system is insufficient for my purposes.

Rufus

(Originally posted Tue 06/30/1998)
The best definition of a real time system is one I got from a textbook I was teaching from, to wit:
“A real-time system is a system that controls an ongoing process and delivers its outputs no later than is necessary for effective control.”
The question of real-time is virtually 100% dependent on the process. Real time control of the dam gates on a slow moving river may require a response time no faster than an hour; real time control of an annealing furnace may require a response time of 30 seconds; for the control surfaces of a jetliner, maybe a few milliseconds; for a Mach 3 fighter it may be fractions of a millisecond.

(Originally posted Wed 07/01/1998)
Dear Mr. Shields,
I hope you forgive me for my changes in the original text.

> “A real-time system is a system that controls an ongoing process and delivers its outputs no later than is necessary for effective control.”<

A control system is a system that controls an ongoing process and delivers its outputs no later than is necessary for effective control.

> The question of real-time is virtually 100% dependent on the process. Real time control of the dam gates on a slow moving river may require a response time no faster than an hour; real time control of an annealing furnace may require a response time of 30 seconds; for the control surfaces of a jetliner, maybe a few milliseconds; for a Mach 3 fighter it may be fractions of a millisecond. <

The question of control is virtually 100% dependent on the process. Control of the dam gates on a slow moving river may require a response time no faster than an hour; control of an annealing furnace may require a response time of 30 seconds; for the control surfaces of a jetliner, maybe a few milliseconds; for a Mach 3 fighter it may be fractions of a millisecond.
The intent of the changes is to ask the following questions:
Are there any comments on these variants of the text?
What does the text lose after the changes?
Does it become more informative?
Does it become more foggy?
Thanks,

Vladimir E. Zyubin
Institute of Automation & Electrometry
Novosibirsk Russia

(Originally posted Wed 07/01/1998)
I think the changes you made illustrate that all control systems are real-time systems. We should strive to use the word “control” instead of the word “real-time” wherever possible. All real-time systems are not control systems though. As an example a data collection program might be considered real-time since all data must be acquired within time constraints, but since no outputs are sent, it is not a control system.
Also, how about if we drop the words “hard” real-time and “soft” real-time and instead give the consequences of failure such as: possible loss of life, large financial loss, small financial loss, the plant will be shut down, etc. There is so much disagreement in the meaning of “hard” and “soft” that I tend to ignore these words and try to figure out the consequences of failure and the timing requirements from other descriptions of the system.
Don.

(Originally posted Thu 07/02/1998)
To my mind, the definition is a real time application is one where the rate of data processing is such the input data can be handled as it becomes available, and output data can be provided as it required. For example, real time generation of computer animation means that the frames are drawn at something like 30 fps. Real time audio compression means that the data stream is compressed as quickly as it is being sampled. The antonym of a “real time” application is thus something like a “batch” application. All control systems must thus by definition be real time applications, or they would not be able to control properly.
The problem comes when people try to apply the words “real time” to operating systems, rather than to application software. It is certainly true that some operating systems make it easier to write real time application than others, but I would maintain that “real time”-ness in the sense I have defined it above is a property of those applications and not of the underlying OS.
When the term is applied to operating systems, it tends to be used to mean that the operating system has low latencies and is deterministic. But neither of these properties is a yes-or-no issue, in that latencies must be considered relative to the time-frame of the application, and determinism is meaningless unless the set of inputs to be used to determine the response in question is defined.
I would thus rather throw away all the overloaded terminology we’re arguing about. I’d much rather refer to operating systems by terms such as “responsive” or “predictable”, as such terms don’t come with all the ill-defined baggage of the more usual language. Indeed, I’d even go as far as saying that it is only particular features of an operating system that should be described in such terms. I’d then much rather leave the term “real time” for applications only, where its meaning is much clearer, and much less open to debate.

Mike Granby
Paradigm Controls Limited
http://www.paracon.demon.co.uk

(Originally posted Thu 07/02/1998)
Nonsense! There is such a thing as a Real-Time operating system. If you have only used Windows you don’t know what one is. I will not repeat the many previous postings related to response time - they are correct. If it is fast enough for the application, it is real-time.
However, any RTOS must provide a way to schedule tasks on a timed basis:
1. Run a task X milliseconds from NOW (scheduled)
2. Run a task every Y milliseconds (cyclic)
3. Run a task at Z, a specified time-of-day

Most RTOS also provide a method to run a task on some external event or alert other than time. Most of the instances, the OS provides some SEMAPHORE mechanism to allow inter-process signaling.
Dick Caro
Richard H. Caro, Vice President
Automation Research Corporation

(Originally posted Fri 07/03/1998)
As an aside, why do you need to bring Windows into this?
It seems to me that your prejudices are showing.
Moving on to the main issue, your definition of a real-time operating system as contained in your posting is simply that of an OS that is capable of providing timer-based scheduling. All three operations that you list are in fact that same thing—the ability to switch to a given task at some particular time, or more precisely (since switching to the task in question might not be possible) the ability to mark that task as ready to run. In fact, I’m not even sure that the time-of-day issue comes into the question of a RTOS at all, as many real-time applications have no need to know anything about the time-of-day!
Anyway, if timer-based scheduling is really the definition of an RTOS, it is so light-weight as to be meaningless, hence my assertion that the term should only be applied to applications. Your requirement to schedule tasks in response to events adds nothing to your definition— all operating systems must have the ability to switch tasks in response to interrupts, as in essence they do little else! As for task synchronisation primitives, these surely have even less to do with the argument, and they can in any case easily be implemented outside the OS.
My main point thus remains that implementing a real-time application— a term about which I would hope there is no debate—does not require a real-time operating system, and a real-time operating system does not guarantee the ability to implement a real-time application. Given that an RTOS is thus neither a sufficient or a necessary condition for a real-time application, I find little merit in applying the term to the operating system at all.

Mike Granby
Paradigm Controls Limited
http://www.paracon.demon.co.uk

(Originally posted Mon 07/06/1998)
Clearly, you have not attempted to implement a real-time application on an O/S that does not have any real-time features. Sure, it can be done -- all you need is access to a low-level timer. Then you need to implement all of the features supported by a RTOS yourself, hopefully as re-entrant and re-usable objects. For those of us that choose to not drive down to low level programming, I prefer to have my O/S provide those features for me. WindowsNT does not. PSOS does. It is all too easy to trivialize the features of past generations of RTOSs which are necessary to implement embedded systems. I still maintain that if an O/S does not support the most basic of time-based scheduling functions, it cannot be called a Real-Time O/S.
By the way, how do I schedule end-of-shift reports if I do not have access to a time-of-day clock?
Dick Caro
Richard H. Caro, Vice President
Automation Research Corporation

(Originally posted Mon 07/06/1998)
Dealing with your closing question first, I did not say that access to
the time-of-day was unnecessary for applications such as the one your
quote. Rather, I disputed your inclusion of time-of-day scheduling in
the definition of an RTOS. I would have thought that it was self-evident
that there exist many real-time applications that do not need
time-of-day information, and that to thus include it in your definition
was superfluous.

Moving back to the main issue again, I would like more information about
this putative timer-based scheduling definition. One can certainly
create a thread in Windows NT which is be run after a given period. Are
you saying that the accuracy with which that time period can be
specified is not sufficient for "real time" applications? If so, is this
down to the existence of over-sized non-interruptible sections of code?
Is it the existence of higher priority threads that refuse to yield the
processor? Or is it the difficulties of performing certain operations
with your thread without yielding control to non-deterministic operating
system services?

I am genuinely interesting in getting to the bottom of this, although
the identification of those features which make something *not* an RTOS
is hardly the same as finding those features which define it.

Mike Granby
Paradigm Controls Limited
http://www.paracon.demon.co.uk

(Originally posted Mon 07/06/1998)
Mike,
I really don't have the time to educate people on a field of technology
well defined by many vendors of products over the past 20 or more years.
If you want to understand what a RTOS is, then buy a book. There are
many. Here is a vendor web site in case you want to start there:
http://www.isi.com/Products/pSOS/
There are many products defined to be a vehicle to HELP the user by
providing the timing and synchronizing functionality users need to solve
problems in multitasking embedded systems. The POSIX project was an
attempt in the UNIX community to provide real-time features in a uniform
way. Your words seem to indicate that you have never heard of a RTOS.
I have lived with Real-Time Operating Systems for most of my career.
Please do not trivialize the existence of an entire industry simply
because it is new to you.

Dick Caro
==============================================
Richard H. Caro, Vice President
Automation Research Corporation

(Originally posted Tue 07/07/1998)
Dick,

I really am sorry to say this, but I find your attitude patronising in
the extreme. You are making many assumption about me and about my level
of knowledge, while avoiding answering the very simple question I asked
in my previous post. If you want to duck-out of this debate then that is
all very well and good, but please don't go around claiming that there
is this wonderful accurate definition of "real time" out there for
anyone to find when this whole thread has been concerned with
pinning-down precisely such a definition.

You made an assertion about Windows NT not being a RTOS, and I attempted
to find out why it did not meet your definition of such a thing. Rather
than answer the question -- which would surely not have taken that much
of your valuable time -- you decided to attack my level of competence.
It may surprise you, but I do have a certain amount of knowledge about
these things. The point is that I am still genuinely at a loss to find a
qualitative definition on an RTOS, and frankly the URL you quote adds
little to what I know.

In your closing paragraph, you say that I have indicated that I have
never seen an RTOS. Let me correct you somewhat. All of *my* career I
have worked with -- and indeed written! -- operating systems that
exactly meet your definition of an RTOS. And that is precisely why I am
still at a loss as to what the big deal is, and why I still maintain my
assertion that the term "real time" is not precisely defined when
applied to operating systems when compared to the exact definition that
exists when it is applied to applications.

Cheers, Mike.

Mike Granby
Paradigm Controls Limited
http://www.paracon.demon.co.uk

(Originally posted Tue 07/07/1998)
Mike,
My apologies. I didn't mean to insult your intelligence. I just find
your style of questioning objectionable. To your questions:

Windows (95, NT, 3.51, etc.) and DOS in all forms are just Disk
Operating Systems. Windows makes the multitasking easier than invoking a
new COMMAND sequence that was necessary in DOS. It also provides easier
to use memory management to take advantage of Extended Memory that is
necessary due to the handicap of the x86 architecture. If you care to
write a program to use low level timers, you may create an entire
real-time environment yourself using DOS or any form of Windows, but the
O/S does not help you in any way. Therefore, IMHO, Windows is NOT a
real-time O/S. I don't know about WinCE 3.0 which Microsoft says will
have at least fast context switching, but there has been no information
on time-based scheduling or task synchronization.

My definition: a real-time O/S provides the services to
deterministically schedule tasks based on time or external events, and
provides the services to synchronize task execution in a multitasking
environment.

Mike, you may be an ace programmer and find real-time routines in some
class-library. That doesn't help most people working on applications
who expect these services to be provided by the O/S. If you care to
follow some obscure references, I was one of the editors of the
Real-Time Extensions to FORTRAN prepared in the 1970's and which became
ANS/ISA S61.1. These were implemented by Modcomp and DEC (and maybe
others) for their FORTRAN compilers. These same extensions were
prepared for PL/I and added to the subset of that language which became
an ANSI standard, but I don't have that reference.

Please note that "real-time" does not in any way define response time
requirements. It only implies that the O/S provides services needed by
tasks to respond in a deterministic way. A genuine RTOS provides the
enforcement that library scheduler routines cannot.

Dick Caro

(Originally posted Tue 07/07/1998)
Your apology is accepted, and fully reciprocated with respect to my
style of questioning should you consider it objectionable. It is not
intended to be so.

Moving on to the question of Windows, I think it is important to make a
distinction between the different members of that family, as they are
all rather different in the areas we are discussing...

With Windows 3.1, the OS that most people see (ie. the GUI) is about as
far from anyone's definition of an RTOS as you could ever get.
Underlying that, though, is the virtual machine manager (VMM) used to
schedule between DOS virtual machines. One of these VMs is running the
GUI, and the others may run anything you like. I would argue that the
VMM meets you definition of an RTOS, in that you can schedule the VMs
according to interrupt events, be they from the timer or from other
external sources. Any attempt to implement a real-time application in
this way is hampered, though, by two things. Firstly, the calls into the
this "operating system under an operating system" can only be made from
virtual device drivers -- which were still most evil at that stage of
Window's evolution -- and, secondly, your entire I/O system is based
upon DOS, with all its non-re-entrant nastiness.

With Windows NT, it is a different kettle of fish altogether. It surely
meets your definition of an RTOS, and it surely does "help you" by
provide flexible scheduling, task and thread synchronisation services,
asynchronous procedure calls, and all manner of fun things. Whether or
not it is responsive enough in terms of latencies to be a true RTOS by
some people's definition is another question, but it is precisely that
quantitative nature of the definition that makes me want to throw the
term away altogether.

With Windows 95, you've got an in-between situation. It provides pretty
much all of the task stuff that you require of an RTOS, but elements of
its I/O system are still less re-entrant and responsive than Windows NT,
and large elements of its GUI are likewise single threaded. But then
again, we're not talking about graphical real-time operating systems
(GRTOS???) so perhaps this isn't relevant.

From all of this, I draw two conclusions. Firstly, all of the Windows
family have some form of scheduler which would meet *some* definition of
an RTOS, even if the latencies didn't meet other people's expectations.
Secondly, those members of the family that have weakness actually have
them in the areas of their I/O systems and their task protection
mechanisms. This fits in with my "what's the big deal" comment --
writing an RT scheduler is trivial; writing an RT I/O system is much
more complex. Even then, though, the concept of RT-ness is a sliding
scale, such that no-one can draw a line in the sand and say where RT
begins, and where it ends. As such, it does not strike me as a useful
term when used in this context.

--
Mike Granby
Paradigm Controls Limited
http://www.paracon.demon.co.uk

(Originally posted Tue 07/07/1998)
Answered in context below:
> Moving on to the question of Windows, I think it is important
> to make a
> distinction between the different members of that family, as they are
> all rather different in the areas we are discussing...
>
> With Windows 3.1, the OS that most people see (ie. the GUI)
> is about as
> far from anyone's definition of an RTOS as you could ever get.
> Underlying that, though, is the virtual machine manager (VMM) used to
> schedule between DOS virtual machines. One of these VMs is running the
> GUI, and the others may run anything you like. I would argue that the
> VMM meets you definition of an RTOS, in that you can schedule the VMs
> according to interrupt events, be they from the timer or from other
> external sources. Any attempt to implement a real-time application in
> this way is hampered, though, by two things. Firstly, the
> calls into the
> this "operating system under an operating system" can only be
> made from
> virtual device drivers -- which were still most evil at that stage of
> Window's evolution -- and, secondly, your entire I/O system is based
> upon DOS, with all its non-re-entrant nastiness.

Win3.1 is only DOS with an ugly GUI and a single threaded multitasking
system. It needed to be run as a slave OS under a real RTOS which most
of the HMI vendors did.

>
> With Windows NT, it is a different kettle of fish altogether.
> It surely
> meets your definition of an RTOS, and it surely does "help you" by
> provide flexible scheduling, task and thread synchronisation services,
> asynchronous procedure calls, and all manner of fun things. Whether or
> not it is responsive enough in terms of latencies to be a true RTOS by
> some people's definition is another question, but it is precisely that
> quantitative nature of the definition that makes me want to throw the
> term away altogether.

Everything you say is correct except that I did not refer to thread
synchronization but for independent tasks (processes) spawned by the
timer. In a real RTOS, it is not necessary to keep a scheduling task
alive as it is in WinNT. Also, WinNT has no means, unless you write the
code, to support deadline scheduling, common in RTOS. The missing factor
is that the OS must enforce the time schedule unless blocked by higher
priority tasks. I guess that you can do all that in WinNT if you write
the code. If I specify an RTOS, I ask that the RTOS enforce these
features. You raise all the same questions that the PL/I designers
raised in 1976 about the need for Real-Time extensions to their favorite
language. It's all about a small matter of programming. Without the
enforcement of the schedule and the synchronization by the OS, it cannot
be considered as Real-Time. Ergo, WinNT, without modification cannot be
considered a RTOS.

> With Windows 95, you've got an in-between situation. It
> provides pretty
> much all of the task stuff that you require of an RTOS, but
> elements of
> its I/O system are still less re-entrant and responsive than
> Windows NT,
..clip ... and therefore less RT.
>
> >From all of this, I draw two conclusions. Firstly, all of the Windows
> family have some form of scheduler which would meet *some*
> definition of
> an RTOS, even if the latencies didn't meet other people's
> expectations.
> Secondly, those members of the family that have weakness actually have
> them in the areas of their I/O systems and their task protection
> mechanisms. This fits in with my "what's the big deal" comment --
> writing an RT scheduler is trivial; writing an RT I/O system is much
> more complex. Even then, though, the concept of RT-ness is a sliding
> scale, such that no-one can draw a line in the sand and say where RT
> begins, and where it ends. As such, it does not strike me as a useful
> term when used in this context.

Easy for you to say, Mike ace programmer. Not easy for an application
programmer to write multithreaded tasks to run real-time. Even harder
to write the OS administrative code to enforce clock synchronization
should task execution run over the allocated time gap. It all boils down
to one issue: how much real-time code must the programmer create to
enforce the real-time scheduling and synchronization tasks required to
implement the application. I say that RTOS like PSOS and Lynx or the
older RSX-11M (DEC PDP-11) and MAX III (Modcomp Classic) mad this job
easy, but I cannot even conceive of the complexity of doing the same
jobs in WinNT.

(Originally posted Tue 07/07/1998)
On Tuesday, July 07, 1998 3:45 PM, Dick Caro wrote:
> I say that RTOS like PSOS and Lynx or the
> older RSX-11M (DEC PDP-11) and MAX III (Modcomp Classic) mad this job
> easy, but I cannot even conceive of the complexity of doing the same
> jobs in WinNT.

As a long time user of the PDP-11, I often wonder why someone doesn't
rewrite RSX to run on Intel. While it didn't always make everything
easy, it did have most of the features a real-time programmer needs.
Even the features it didn't have could usually be added or synthesized.

Les

(Originally posted Wed 07/08/1998)
Great idea. Unfortunately, the PDP-11 hardware did a lot of the work.
It had 16 levels of priority interrupt and automatic context switching
in interrupt response. One way to do important stuff (like incrementing
a flow integrator) was to do it in the interrupt level. Pentium has
only 4 hardware interrupt levels, but is much faster than the PDP-11 in
any form.

Dick Caro

(Originally posted Wed 07/08/1998)
YOU SAID: "Everything you say is correct except that I did not refer to
thread synchronisation but for independent tasks (processes) spawned by
the timer."

Most self-proclaimed RT operating systems I have looked at only support
threads, and only a few support self-contained processes with separate
address spaces. By a thread, I mean a unit of execution which shares the
same code and data space as a number of similar units of execution.

YOU SAID: "Also, WinNT has no means, unless you write the code, to
support deadline scheduling, common in RTOS. The missing factor is that
the OS must enforce the time schedule unless blocked by higher priority
tasks."

So now you are adding dealing scheduling to the definition of an RTOS?
There is plenty of evidence against this assertion. Let us consider AMX
-- the first RTOS that I used in an industrial application. This does
not provide deadline scheduling. Further, let us consider PSOS -- the
RTOS that you suggested I study. The description of the PSOS scheduler
that I found on a Phillips web site is remarkably similar to that of
Windows NT, and of many other priority-based schedulers. There is
absolutely no mention of deadline scheduling. Further, let us consider
the July 1998 version of the comp.realtime FAQ which includes in its
definition of an RTOS the requirement that "The notion of thread
priority has to exist as there is for the moment no deadline driven OS."

In other words, the commonly used definition of an RTOS does not include
the notion of deadline scheduling. Rather, it includes the
priority-based scheduling that Windows NT (and indeed Windows 95)
implements. You may still feel that neither of these operating systems
is an RTOS, but the fact remains that BY YOUR DEFINITION -- less the
recently added requirement for deadline scheduling -- they are precisely
that.

YOU SAID: "Easy for you to say, Mike ace programmer."

Oh, stop it.

Mike Granby
Paradigm Controls Limited
http://www.paracon.demon.co.uk

(Originally posted Wed 07/08/1998)
Not to prolong the issue, but I still insist that to qualify as a RTOS I
ask for the following:

1. Ability to schedule an independent task to execute at some future
time increment (from now). This can also be a delay in task thread
execution. The schedule cannot be masked by execution of a lower
priority task/thread.

2. Ability to schedule an independent task to cyclically execute at a
precise time interval. I am not sure how I do this with an execution
thread.

3. Ability to queue a task execution (or resume a program thread) when
an external event occurs. External event may be a program (shared
memory) semaphore, or it may be a bit in a register of a scanned I/O
database.

I look for being able to do these operations for independent tasks by
configuration of queuing tables, not by programming. At very worst,
the scheduling task is very small.

I don't find these functions as part of the Windows NT specifications.
I am sure that it is possible to write the queuing tasks and to create a
queue manager with some reasonable high level of performance on say a
P400 processor, but it isn't part of NT.

In short, if the OS doesn't have Real-Time features, how can it be a
RTOS?

Dick Caro

(Originally posted Thu 07/09/1998)
1. Spawn a high-priority thread which sleeps for N ms and then wakes
your other thread. Okay, so you need a bit of code, but we're talking
about ten lines or so to create the framework, and a single line to
invoke it each time.

2. Similar idea to above, but use a waitable timer within the helper
thread. If you're not running Windows NT 4.0 and so don't have a
waitable timer available, then you're okay as long as the time taken to
wake a thread is less than a system tick. This is pretty much the case
on any system built within the last few years.

3. I/O database triggered resumes need a scanning task, but is easy to
do and I've not seen a single RTOS that does this out-of-the-box. Having
a task resume from a semaphore is part of Windows NT, and thus requires
no extra effort. This can be done between threads, or across processes.

The first point is thus that you can get Windows NT to do all these
things, albeit with some user-mode coding. The more important point,
however, is that many many operating systems which claim to be RTOS's
require exactly the same amount of coding as Windows NT. You thus appear
to have two choices: Admit that Windows NT is (by a commonly used
definition) an RTOS, or admit that the term has no value! :-)

--
Mike Granby
Paradigm Controls Limited
http://www.paracon.demon.co.uk

(Originally posted Fri 07/10/1998)
Dick your first point is all cool and groovey but even in a PLC,
which IMHO is by definition RTOS a task only occurs within the
contraints of scan time.

You may set a timer to trigger a task but this timer will only
be accurate within the contstraints of scan time. Even with an
interrupt driven timer accuracy down to 1us might be the best
you can hope for.

So I guess if knowing your task will trigger in this us or the
next is close enough then this is RTOS.

(Originally posted Wed 07/15/1998)
With all due respect Dick,

I am not sure what you mean by 'Windows NT Specifications'. I respectfully suggest
that you look directly at the API. It contains (and I am not saying this is a complete list):

- calls to adjust the priority of threads,
- calls to manage multiple threads, and manage multiple processes,
- calls implementing 'interprocess' synchronization primitives such as
semaphores, mutexes etc. These can synch threads within or between processes.
- interprocess communication primitives.
- block/release a thread on single or multiple events (a daemon).

You said something about not considering something found in a class library, but I am
not sure why you would say this when in most cases the classes are thin wrappers over the
Win32 API.

Please understand that what I am saying only applies to the full NT implementation of
the Win32 API, not Win32s, not Windows 95 and most certainly not Windows 3.x or earlier.
Taking properties of Win3.x and drawing conclusions about Win32 (NT) is not comparing
apples to apples.

I don't view the techniques I use writing multi-threaded applications under Win32 as
being a whole lot different than those used writing in Micropower Pascal on DEC machines
in an earlier life.

Bill Code
MPM Engineering Ltd.
4-6240 202nd St., Langley, B.C., Canada, V2Y-1N2
E-Mail: Bill_Code@mpm-eng.com WWW: http://WWW.MPM-ENG.COM/

(Originally posted Tue 07/07/1998)
I think I would have to agree with Mike Granby that the term "RTOS" just
does not have much value anymore.

It used to mean (for me) a small, embedable kernel which was optimized
for computer hardware support of automation/control applications. Today
though, many of the scheduling, I/O and sychronization features that
were typically provided by that class of product are now provided (to
greater and lessor extent) by general purpose OS's, the difference being
largely speed and size.

In fact, many "real time" applications are now being successfully
supported by general purpose OS's. For better, or worse, the difference
between these classes has decreased greatly.

(Originally posted Tue 07/07/1998)
RTOS is still a valuable term. Many slow, non-critical real-time
applications can be run on a general purpose OS with at least some extra
work from the programmer. There are also real-time packages written for
general purpose operating systems that to some degree make up for what is
lacking in the OS. There is a big difference though between, say, QNX and
Windows 95 in terms of OS support for real-time applications. When I here
the term RTOS it may need some qualification, but I instantly know that
there are at least some features commonly needed by real-time applications
built into the OS. By the way, the term operating system itself is not very
precise either. What features are necessary before you can call it an
operating system? If you ask 10 different people you will get 10 different
answers, but that does not mean the term operating system has no value. And
which general purpose operating systems do you refer to that are just as
good as any RTOS for implementing time critical real-time applications
where failures could result in result in injury and/or large financial losses.

Don.

(Originally posted Wed 07/08/1998)
>RTOS is still a valuable term. ...............<

I will take your word that it is still valuable for you. It probably has
some for me too. But, for me, it would be hard to attach much
preciseness to it.

> ............And which general purpose operating systems do you
refer to that are just as
good as any RTOS for implementing time critical real-time
applications
where failures could result in result in injury and/or large
financial losses.....................<

I don't think I have ever said that general purpose OS's are better at
real time applications than some other
designed-for-real-time-applications OS. I did say that some successful
real time applications have been installed that run on general purpose
OS's. There is a big difference. Certainly, different OS's have
differering strengths and weaknesses.

(Originally posted Wed 07/08/1998)
Subject: SOFT: "Real-Time Debate"

In my younger days we referred to this type of debate as "Catching the
mice, but letting the elephants free."

At the risk of getting further embroiled, I would like to offer the
following solution:

Why not use the "official" definition given in IEEE Std 100-1992 (at
least thru the 5th edition)?.

Phil Corso,
TRIP-A-LARM CORP.

(Originally posted Wed 07/08/1998)
I was hoping to not get embroiled, but the answer to your question is:

Page 1083 of the aforementioned IEEE standard.

Phil Corso,
Trip-A-Larm Corp


Mike Granby wrote:

>Sounds like a good idea. What is it?

(Originally posted Mon 07/20/1998)
It must not be such a good idea, since most academic
researchers in real-time computing don't agree with that
definition.

Doug

(Originally posted Thu 07/09/1998)
>I think I would have to agree with Mike Granby that the term "RTOS" just
>does not have much value anymore.

That means the upcoming RTOS version of WinCE has no additional values
compared to the existent versions ??

No value ? ... ask Microsoft how much this development cost :-)

>It used to mean (for me) a small, embedable kernel which was optimized
>for computer hardware support of automation/control applications. Today
>though, many of the scheduling, I/O and sychronization features that
>were typically provided by that class of product are now provided (to
>greater and lessor extent) by general purpose OS's,

Would be nice ... but this is not the reality.

> the difference being largely speed and size.

There are other important attributes ...

>In fact, many "real time" applications are now being successfully
>supported by general purpose OS's. For better, or worse, the difference
>between these classes has decreased greatly.

It depends on your definition of real-time applications ...

Armin Steinhoff

http://www.DACHS.net

(Originally posted Tue 07/07/1998)
At 09:10 07.07.98 +0100, Mike Granby wrote:
>Dick,
>
[ ... ]
> ...... and why I still maintain my assertion that the term "real time"
is not precisely defined when applied to operating systems when compared
to the exact definition that exists when it is applied to applications.

Mike ... what is the exact definition of real-time "when it is applied to
applications" ??

Here is my set of ATTRIBUTES which a real-time system must have ... when I
call it a real-time system.


ATTRIBUTES of REAL-TIME systems.

REAL-TIME Systems in general (minimum requirements)

HARDWARE
- supports at least one interrupt level
- CPU reacts to interrupts
- CPU supports context switching

SOFTWARE
- event driven management of system resources
- deterministic response times to events with a predictable jitter
- deadlines for the processing of events are met with a
predictable jitter
- supports priority levels for task processing
- supports fast context switching of tasks


HARD REAL-TIME Systems

HARDWARE
- supports different interrupt levels (priorities)
- allows nesting of interrupts
- CPU reacts fast to interrupts in the range of nanoseconds
- CPU supports fast context switching in the range to nanoseconds

SOFTWARE
- event driven management of all system resources
- priority levels for interrupt processing
- supports nesting of interrupts

- deterministic response times to events with a worst case
predictable jitter in the maximal range of 10 microseconds

- deadlines for the processing of events are met with a worst case
predictable jitter in a maximal range of 10 microsecond

- supports priority levels for task processing ( 256 at bests ...)
- supports fast context switching of tasks in the range of
microseconds
- supports different scheduling policies (POSIX)


SOFT REAL-TIME Systems

HARDWARE
- support of different interrupt levels (priorities)
is not coercive required
- nesting of interrupts is not coercive required
- CPU reacts to interrupts in the range of 100 miroseconds
- CPU supports context switching in the range to 100 microseconds

SOFTWARE
- management of system resources is not 100% bound to external events
(print and wait ...:-)

- priority levels for interrupt processing
- support of nested interrupts is not coercive required

- deterministic response times to events with a predictable jitter
in the maximal range of 100 microsecond

- deadlines for the processing of events are met with a predictable
jitter in a maximal range of 10 millisecond

- supports priority levels for task processing
- supports of context switching of tasks in the range of milliseconds
- support of different scheduling policies is not coercive required

Armin Steinhoff

<http://www.dachs.net/>

(Originally posted Wed 07/08/1998)
> "What is the exact definition of real-time [applications]?"

It was contained in an earlier post. In short, my definition of a
real-time application is one where input data is processed as it
arrives, and output data is provided as it is needed. It is the opposite
of old-style batch or off-line processing. All control systems are by
definition real time applications, or they'd be unable to control
things.

> 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. 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], 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.

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.

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. Determinism at the OS level is thus only part of it -- the
really important determinism is that of the application-OS system as a
whole.

Mike Granby
Paradigm Controls Limited
http://www.paracon.demon.co.uk

(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

(Originally posted Tue 07/07/1998)
Hey Armin,

The definitions here have absolutely NO meaning, as you do not specify the
system this is being inserted into. The numbers you quote could be
ridiculous (too fast or too slow) depending on the system you are
controlling. As for requiring multiple interrupts levels, this is *not* a
requirement, e.g. if I destine a processor, microcontroller, ASIC, FPGA,
abacus, pocket calculator, etc. (depending on the selected technology) to
handle each event, I do not require multiple interrupt levels, I do not even
need interrupts, as I can run a polling system, which if it handles all
events "predictably given the systems time constraints" then what's the
problem?

As I said before *if you don't specify the system, real-time has no
meaning*. If a general purpose quantitative measure is required then it
should be something along the lines of:

REAL-TIME System:
A system that is guaranteed to handle all events within the time constraints
dictated by the physical system with which it is connected.

HARD REAL-TIME:
A real-time system in which the timeliness of the event handling is
guaranteed primordially by its physical configuration.

SOFT REAL-TIME:
A real-time system in which the timeliness of the event handling is
guaranteed by a combination of its physical and logical configurations.

This is a first stab, anyone want to improve on it?

Simon Martin
mailto:smartin@reuna.cl

(Originally posted Thu 07/09/1998)
Hi Martin,

At 17:54 07.07.98 -0400, you wrote:
>Hey Armin,
>
>The definitions here have absolutely NO meaning, as you do not specify the
>system this is being inserted into.

It has absolutely a meaning for the concrete "technological" reqirements
... for the real existing classes of real-time systems.

> The numbers you quote could be ridiculous (too fast or too slow)
depending on the system you are controlling.

Yes ... of cause :-). But you must define limits for differentiations ...
and these limits are always in question.

>As for requiring multiple interrupts levels, this is *not* a requirement,

A realtime system must respond to external events ... at least to manage
the most important resource - the CPU - . This must also be possible when
the CPU handels an event triggered by an hardware interrupt ... so you need
an interrupt with a higher hardware priority to serve immediately the more
important external event.

> e.g. if I destine a processor, microcontroller, ASIC, FPGA,
>abacus, pocket calculator, etc. (depending on the selected technology) to
>handle each event, I do not require multiple interrupt levels, I do not even
>need interrupts,

Interesting theory ... how do you control the different polling loops ??
How would you assign the CPU to the polling loops ???

> as I can run a polling system, which if it handles all
>events "predictably given the systems time constraints" then what's the
>problem?

Yes ... it works just for a specific class of application. But what happens
when the whole polling process takes 20ms ... and you have to respond
predictably in the time range of 50 us ... to meet the deadline of the
processing of an external event e.g. in the time range of 1ms ???

>As I said before *if you don't specify the system, real-time has no meaning*.

I talked about ATTRIBUTES of 'real-time' computer systems based on the
existing technology ... so there is a clear meaning.

> If a general purpose quantitative measure is required then it
>should be something along the lines of:
>
>REAL-TIME System:
>A system that is guaranteed to handle all events within the time constraints
>dictated by the physical system with which it is connected.

Good general definition .... as long as "time constrains" means "meeting of
all
deadlines" .

( In the real world you have to define a predictable worst case variation
in meeting of deadlines ...)

>HARD REAL-TIME:
>A real-time system in which the timeliness of the event handling is
>guaranteed primordially by its physical configuration.

Too general ... I don't see any differences to the definition of REAL-TIME !

>SOFT REAL-TIME:
>A real-time system in which the timeliness of the event handling is
>guaranteed by a combination of its physical and logical configurations.

This definition is not from (and for) this world ... guaranteed :-)

Armin Steinhoff

http://www.DACHS.net

(Originally posted Fri 07/10/1998)
Back again. Am I a sucker for punishment or what???

The whole gist of my previous mail was supposed to be that real-time has no
meaning in general terms, only in specific instances. Saying that a Windows
NT, QNX, POSIX, etc. is real-time,or not, per se, is like saying all cars
can do over 150 mph (this is true, drive a car off a cliff and measure the
terminal velocity!!) It depends on the circumstances!!!

With respect your comments: (answers in line)

<snip>
> > The numbers you quote could be ridiculous (too fast or too slow)
> > depending on the system you are controlling.
>
> Yes ... of cause :-). But you must define limits for differentiations ...
> and these limits are always in question.


If we are going to use limits to differentiate between real-time and non
real-time then these limits must be applicable WHATEVER CHARACTERISTICS OF
ANY GIVEN SYSTEM. Given the number of different possible characteristics,
then the only way I can see using limits is by defining them as some
function of these characteristics. What characterisitics do you use to set
the limits and how do you define the functions? That is a different subject
which we could elaborate on, if anyone wants to... (I do)

<snip>
> > e.g. if I destine a processor, microcontroller, ASIC, FPGA,
> >abacus, pocket calculator, etc. (depending on the selected technology) to
> >handle each event, I do not require multiple interrupt levels, I do not
even
> >need interrupts,
>
> Interesting theory ... how do you control the different polling loops ??
> How would you assign the CPU to the polling loops ???


How about power-on. Initialise master processor. Initialise environment for
each subsidiary processor. Release subsidiarty processors. Done.

> > as I can run a polling system, which if it handles all
> >events "predictably given the systems time constraints" then what's the
> >problem?
>
> Yes ... it works just for a specific class of application. But what
happens
> when the whole polling process takes 20ms ... and you have to respond
> predictably in the time range of 50 us ... to meet the deadline of the
> processing of an external event e.g. in the time range of 1ms ???

You said that interrupts are a requirement for a system to be considered
real-time. You agree some systems do not require interrupts to be considered
real-time. These two statements are mutually inconsistent. All I tried to
show is that to imply interrupt handling as a requirement for real-time
processing
is incorrect, and therefore should *not* be a part of a the definition of a
real-time system.

> >As I said before *if you don't specify the system, real-time has no
meaning*.
>
> I talked about ATTRIBUTES of 'real-time' computer systems based on the
> existing technology ... so there is a clear meaning.


You have only specified HALF of the system with this. The computer system.
All this system must do is react to the stimulii from the external system
within a given set of time constraints (deadlines). You must specify the
stimulii and the deadline ATTRIBUTES as well, in order to have any meaning.
If we use your definition of SOFT REAL-TIME as the basis of a hypothetical
tungsten filament lighting control system, you have overkill by a factor of
several 1000. It would be like killing a mouse with a missile, it'd kill the
mouse but isn't there an easier/cheaper/more efficient way of achieving the
same result without losing any apparent functionality or flexibility.

> > If a general purpose quantitative measure is required then it
> >should be something along the lines of:
> >
> >REAL-TIME System:
> >A system that is guaranteed to handle all events within the time
constraints
> >dictated by the physical system with which it is connected.
>
> Good general definition .... as long as "time constrains" means "meeting
of
> all deadlines" .


That was my intention...

> ( In the real world you have to define a predictable worst case variation
> in meeting of deadlines ...)


My first big difficulty. If you are suggesting that not meeting deadlines is
real-time as long as you have predictable worst cases, I hope you're never
involved in the design/construction of life threatening machinery (i.e.
anything with moving parts). It is dangerous enough comissioning new
equipment without wondering whether the response is stable... For example if
I specify a mechanical relay control system, and specify that the
predictable worst case variations is about 10 minutes (someone got hurt,
technician found the faulty relay, technician changed said relay), then I
should be shot.

In my opinion, not meeting deadlines must be considered a fatal fault.
Immediate transition to safe state should ensue. The definition of safe
state depends on the "physical" system.

> >HARD REAL-TIME:
> >A real-time system in which the timeliness of the event handling is
> >guaranteed primordially by its physical configuration.
>
> Too general ... I don't see any differences to the definition of REAL-TIME
!


The difference is that I specified that the physical configuration is
responsible for the real-timeness of the system.

> >SOFT REAL-TIME:
> >A real-time system in which the timeliness of the event handling is
> >guaranteed by a combination of its physical and logical configurations.
>
> This definition is not from (and for) this world ... guaranteed :-)


I thoroughly agree. I supplied these in order to get people to think what is
really required. As I learnt a long time ago in tech support, never give the
answer as part of the question, otherwise you'll just hear "Yeah, green
light, that's right" or something of the type when it's really red and the
guy never checked.

Ok, if you want something more concrete then what I would like to see for
these measures would be:

HARD REAL-TIME:
Maximum time to handle a given event <= 10% physical system's maximum
Total event handling capacity >= 10 times the physical system's maximum

SOFT REAL-TIME:
Maximum time to handle a given event <= physical system's maximum
Total event handling capacity >= physical system's maximum

This guarantees timeliness of all event handling and allows for some
differentiation between the different types of real-time systems. What
parameters do you use here? What characteristics and relationships are
relevant?

Simon Martin
mailto:smartin@reuna.cl

(Originally posted Fri 07/17/1998)
Good morning/afternoon/evening,

On Fri, 10 Jul 1998, Simon Martin wrote:
<snip>
> ... I supplied these in order to get people to think what is
> really required. As I learnt a long time ago in tech support, never give the
> answer as part of the question, otherwise you'll just hear "Yeah, green
> light, that's right" or something of the type when it's really red and the
> guy never checked.

I'm sorry that I have broken into your extremely interesting
conversation. But if the bellow is a trick to get people to think
then I have definitely caught this bait. :-)

> Ok, if you want something more concrete then what I would like to see for
> these measures would be:
>
> HARD REAL-TIME:
> Maximum time to handle a given event <= 10% physical system's maximum
> Total event handling capacity >= 10 times the physical system's maximum
>
> SOFT REAL-TIME:
> Maximum time to handle a given event <= physical system's maximum
> Total event handling capacity >= physical system's maximum
>
> This guarantees timeliness of all event handling and allows for some
> differentiation between the different types of real-time systems. What
> parameters do you use here? What characteristics and relationships are
> relevant?

It seems to me that 10% looks very strange for the definition
that pretends to be strict. And I can not understand which way it
can guarantee timeliness of all event handling... Well, perhaps,
if there are only 10 unified event sources in the control system.

IMO, to guarantee timeliness of all event handling, the
following conditions must be true (just for a control system
with events handled by interrupt service routines):

I
Sum(Max(i)) <= Tmin(j), where
i=1

Max(i) - maximal time to handle an event i, i = 1,2,...,(I-1),I;
I - quantity of asynchronous events in the system;
Tmin(j) - minimal required response time for the system
(supposedly, it is equal to the response time of an event
j).

I.e., to mathematically test the control system, we have
to:

1. Choose the minimal required response time from required
response times of all events that there are in the control
system -- Tmin(j);

2. Calculate maximal handling time for every event of the
system -- Max(i), i = 1, 2, 3, ..., I;

I
3. Sum the results -- Sum(Max(i));
i=1

4. Compare the result with the minimal required response time.

If the result less or equal to the minimal required response time
then you are King of the Controlled Object.

Note: It is neither applicable for all possible control
systems nor strict mechanism. It is just my humble attempt to
make the things a bit clear. For example, a) for a control system
with a polling mechanism it is not the case, b) ditto if the
required response times is very different, etc... I.e., if there
is necessity then control systems, data acquisition systems, and
other digital applications should be categorized via mechanism
utilized in order to provide implementation of the requirements
of the technical specification for development. IMO.

By the way, the requirements in overwhelming majority of
the cases are stated with the simple sentence:
The accuracy shall be no worse than... ;-)
arenŠt it?

Regards,

Vladimir E. Zyubin
mailto:zyubin@iae.nsk.su
Institute of Automation & Electrometry
Novosibirsk Russia

"In mathematics all is simple: any problem either is trivial
or has no solution... :-)"
E. Zakhryamin (mathematician, my old pal)

(Originally posted Wed 07/29/1998)
Thanks Vladimir,

I stand (er sit) corrected. I think we need a mix of the 2 to insure
timeliness, such that:

Let P be a physical process
Let D be a control device
Let S be a system consisting of P to be controlled D
Let Event be the set of all events to be handled by RS
Let n be the number of events in Event
Let e(i) be the i-th element of Event
Let Tmaxp(i) be the maximum time permissible by P for D to handle event
e(i)
Let Tmaxd(i) be the maximum time D will take to handle event e(i)
Let Cthroughput be defined as the following condition:
n n
Sum f*Tmaxd(i) <=3D Sum Tmaxp(i) (This I take to be your
definition)
i=3D0 i=3D0
Let Ctimeliness be be defined as the following condition:
f*Tmaxd(i) <=3D Tmaxp(i) 0<=3Di<=3Dn (This I take from my original
definition)

If Cthroughput and Ctimeliness hold true for f=3D1 =3D> S can be
considered realtime
If Cthroughput and Ctimeliness hold true for f=3D0.8 =3D> S can be
considered soft realtime
If Cthroughput and Ctimeliness for f=3D0.1 =3D> S can be considered
hard realtime

This definition makes sure that ALL events can be processed, and ALL
events are timely.

A different approach for soft realtime might be to lift the restriction
on Ctimeliness and just make sure that all events are handled, e.g.

If Cthroughput holds true for f=3D0.8 =3D> S can be considered soft
realtime

Any more contributions. (This is fun, but then again I have a strange
sense of humour)

Simon Martin

(Originally posted Fri 07/31/1998)
Hello to everybody,

At Fri, 17 Jul 1998 16:36:49 -0400 Simon Martin wrote:
>
> I stand (er sit) corrected. I think we need a mix of the 2 to insure
> timeliness, such that:
>
> Let P be a physical process
> Let D be a control device
> Let S be a system consisting of P to be controlled D
> Let Event be the set of all events to be handled by RS
> Let n be the number of events in Event
> Let e(i) be the i-th element of Event
> Let Tmaxp(i) be the maximum time permissible by P for D to handle event
> e(i)
> Let Tmaxd(i) be the maximum time D will take to handle event e(i)

Accepted. Excellent notation.

> Let Cthroughput be defined as the following condition:
> n n
> Sum f*Tmaxd(i) <= Sum Tmaxp(i) (This I take to be your definition)
> i=0 i=0

Just a comment:
My original condition expressed in your notation will look like:

n
Sum Tmaxd(i) <= Min{Tmaxp(i)}, where
i=0

Min{Tmaxp(i)} - the minimal time of the set of Tmaxp(i).

I.e., if there is only 2 event in the system -- e(0) and e(1),
and, for instance, Tmaxp(0) = 1000 sec and Tmaxp(1) = 1 sec,
then the Min{Tmaxp(i)} = 1 sec.
(I do understand that this condition is extremely
rigorous, but it deliver us from consideration of order of the
event handling. Please, keep in mind that the (asynchronous)
events can appear =simultaneously=)

> Let Ctimeliness be be defined as the following condition:
> f*Tmaxd(i) <= Tmaxp(i) 0<=i<=n (This I take from my original definition)
>
> If Cthroughput and Ctimeliness hold true for f=1 => S can be
> considered realtime
> If Cthroughput and Ctimeliness hold true for f=0.8 => S can be
> considered soft realtime
> If Cthroughput and Ctimeliness for f=0.1 => S can be considered
> hard realtime

Just a couple of remarks:

1. It seems to me that "f" (I assume that "f" is just a constant)
must be on the right side of the equations. I.e.,

n n
Sum Tmaxd(i) <= f*Sum Tmaxp(i)
i=0 i=0

Tmaxd(i) <= f*Tmaxp(i) 0<=i<=n.

Otherwise, for f=0.0 you will have that Cthroughput and
Ctimeliness hold true for any system.

2. The 0.8 and 0.1 look very strange to me... why not
0.79999(9) or 0.1111111(1)? or Why not e^-1 (1/2.718281...)? :-)

> This definition makes sure that ALL events can be processed, and ALL
> events are timely.

I am not sure... However, perhaps, I misunderstood
something. If so, please explain.

> A different approach for soft realtime might be to lift the restriction
> on Ctimeliness and just make sure that all events are handled, e.g.
>
> If Cthroughput holds true for f=0.8 => S can be considered soft
> realtime
>
> Any more contributions. (This is fun, but then again I have a strange
> sense of humour)

Oh, Simon, all what I can... :-)

Best Regards,

Vladimir E. Zyubin
Institute of Automation & Electrometry
Novosibirsk Russia

(Originally posted Tue 08/04/1998)
Hi all,

I've been talking this through with a friend and we have come to the
conclusion that the concept of "determinism" must also be included in the
definiton, so using some of Vladimir's corrections of my original post,
let's try again:

Let P be a physical process
Let D be a control device
Let S be a system consisting of P to be controlled D
Let Event be the set of all events to be handled by S
Let n be the number of events in Event
Let e(i) be the i-th element of Event
Let Tmaxp(i) be the maximum time permissible by P for D to handle event e(i)
Let Twander(i) be the maximum time deviance permissible by P for the
response to event e(i)
Let Tmaxd(i) be the maximum time D will take to handle event e(i)
Let Tmind(i) be the minimum time D will take to handle event e(i)
Let h be an arbitrary constant in the range 0<h<=1 which measures the
"harshness" of the conditions that define a real time system.
Let Cthroughput be defined as the following condition:
n n
Sum Tmaxd(i) <= h*Sum Tmaxp(i)
i=0 i=0
Let Ctimeliness be defined as the following condition:
Tmaxd(i) <= h*Tmaxp(i) 0<=i<=n.
Let Cdeterminism be defined as the following condition:
Tmaxd(i)-Tmind(i) <= Twander(i) 0<=i<=n

If Cdeterminism, Cthroughput and Ctimeliness hold true for h=1 then S can be
considered realtime

If Cdeterminism, Cthroughput and Ctimeliness hold true for f=0.8 => S can be
considered soft realtime
If Cthroughput and Ctimeliness for f=0.1 => S can be considered hard
realtime


With respect Vladimir's observations
<snip>
>Just a couple of remarks:
>
>1. It seems to me that "f" (I assume that "f" is just a constant)
>must be on the right side of the equations. I.e.,
> Otherwise, for f=0.0 you will have that Cthroughput and
>Ctimeliness hold true for any system.
>
Thanks Vladimir, you can tell that it's been a long time since I last had to
do a formal proof.
>2. The 0.8 and 0.1 look very strange to me... why not
>0.79999(9) or 0.1111111(1)? or Why not e^-1 (1/2.718281...)? :-)
>
It's ok to define things, but in order to take decisions then we have to
some quantifiable measure. Where do we draw the line between hard and soft
realtime? This was just my first stab at some values for defining,
quantitively, not qualitively, when to consider a system real time, and
furthermore when it is hard real time or soft real time. The value for the
"harshness" factor must be set by someone who knows more than me and can
justify the values given, but I had to have a go!!!
>> This definition makes sure that ALL events can be processed, and ALL
>> events are timely.
>
> I am not sure... However, perhaps, I misunderstood
>something. If so, please explain.
>
The condition Cthroughput will assure that the system will be able to handle
all the events that physical system generates within the restraints given by
this physical system.

The condition Ctimeliness will assure that each event will be handled within
the restrictions given by the physical system. Cthroughput is a consequence
of Ctimeliness, but I separated out both conditions for 2 reasons:

a) to be able to force a certain "slack" in the system, i.e. the system is
able to handle more events than the physical system because engineers are
very good at using Occam's Razor, quite often ignoring the non-ignorable. I
know, I'm an engineer!!!!!!

b) reading Armin's mails, there may be some rope in letting a system handle
the throughput, but not reach every deadline. This really gives me the
willies, but I defer to people who may know more, or different things, than
I do (the difference between a good solution and an optimum solution)
<snip>

I decided not to use Vladimir's definition:
n n
sum Tmaxd(i) <= min Tmaxp(i)
i=0 i=0
as I feel this is too harsh. I don't think that there are many systems that
can respond to ALL events within the maximum time to handle the most
demanding event.

Hope this discussion continues. :-)

Simon Martin

(Originally posted Thu 08/06/1998)
>Let P be a physical process
>Let D be a control device
>Let S be a system consisting of P to be controlled D
>Let Event be the set of all events to be handled by S
>Let n be the number of events in Event
>Let e(i) be the i-th element of Event
>Let Tmaxp(i) be the maximum time permissible by P for D to handle event e(i)
>Let Twander(i) be the maximum time deviance permissible by P for the
>response to event e(i)
>Let Tmaxd(i) be the maximum time D will take to handle event e(i)
>Let Tmind(i) be the minimum time D will take to handle event e(i)
>Let h be an arbitrary constant in the range 0<h<=1 which measures the
>"harshness" of the conditions that define a real time system.
>Let Cthroughput be defined as the following condition:
> n n
> Sum Tmaxd(i) <= h*Sum Tmaxp(i)
> i=0 i=0
>Let Ctimeliness be defined as the following condition:
> Tmaxd(i) <= h*Tmaxp(i) 0<=i<=n.
>Let Cdeterminism be defined as the following condition:
> Tmaxd(i)-Tmind(i) <= Twander(i) 0<=i<=n
>
>If Cdeterminism, Cthroughput and Ctimeliness hold true for h=1 then S can be
>considered realtime
>
>If Cdeterminism, Cthroughput and Ctimeliness hold true for f=0.8 => S can be
>considered soft realtime
>If Cthroughput and Ctimeliness for f=0.1 => S can be considered hard
>realtime
>

Good definition !! The definition of Cthroughput shows the absolute worst
case ... multiplied with a simultaneousness factor ( defined by P) gives
more realistic values for the neccessary computing power.

>b) reading Armin's mails, there may be some rope in letting a system handle
>the throughput, but not reach every deadline.

When I remember right, my point was the variation of 'reaching a deadline'
... the approach was to use the precision of reaching a deadline for the
differentiation between soft and hard realtime behavior.

Regards

Armin Steinhoff

http://www.DACHS.net

(Originally posted Fri 08/07/1998)
Dear List,

At Tue, 4 Aug 1998 11:52:27 -0400 Simon Martin wrote:
<snip>
=============== TERMINOLOGY ===================
> Let P be a physical process
> Let D be a control device
> Let S be a system consisting of P to be controlled D
> Let Event be the set of all events to be handled by S
> Let n be the number of events in Event
> Let e(i) be the i-th element of Event
> Let Tmaxp(i) be the maximum time permissible by P for D to handle event
> e(i)
> Let Twander(i) be the maximum time deviance permissible by P for the
> response to event e(i)
> Let Tmaxd(i) be the maximum time D will take to handle event e(i)
> Let Tmind(i) be the minimum time D will take to handle event e(i)
> Let h be an arbitrary constant in the range 0<h<=1 which measures the
> "harshness" of the conditions that define a real time system.
> Let Cthroughput be defined as the following condition:
> n n
> Sum Tmaxd(i) <= h*Sum Tmaxp(i)
> i=0 i=0
> Let Ctimeliness be defined as the following condition:
> Tmaxd(i) <= h*Tmaxp(i) 0<=i<=n.
> Let Cdeterminism be defined as the following condition:
> Tmaxd(i)-Tmind(i) <= Twander(i) 0<=i<=n

========= DEFINITION OF REAL-TIME (APPLICATION)
==========================
> If Cdeterminism, Cthroughput and Ctimeliness hold true for h=1 then S can
> be
> considered realtime
>
> If Cdeterminism, Cthroughput and Ctimeliness hold true for f=0.8 => S can
> be
> considered soft realtime
> If Cthroughput and Ctimeliness for f=0.1 => S can be considered hard
> realtime
=================================================
<snip>

> >2. The 0.8 and 0.1 look very strange to me... why not
> >0.79999(9) or 0.1111111(1)? or Why not e^-1 (1/2.718281...)? :-)
> >
> It's ok to define things, but in order to take decisions then we have to
> some quantifiable measure. Where do we draw the line between hard and soft
> realtime? This was just my first stab at some values for defining,
> quantitively, not qualitively, when to consider a system real time, and
> furthermore when it is hard real time or soft real time. The value for the
> "harshness" factor must be set by someone who knows more than me and can
> justify the values given, but I had to have a go!!!

I think nobody can justify the values because there are no criteria (I don't see at least). Where do we draw the line between hard and soft realtime? - IMO, the correct question would
be: what is reason we have to draw this line? What is value of the terms? Especially, when there are so many orthogonal definitions. It was very demonstrative when your discussion with Mr.Steinhoff about "hard/soft real time systems"
was ended by Mr.Steinhoff's sentence that he was speaking about hard/soft real time =operating= systems... I bet that words like "control" or "operating" could not allow us to get this
curious situation.

> >> This definition makes sure that ALL events can be processed, and ALL
> >> events are timely.
> >
> > I am not sure... However, perhaps, I misunderstood
> >something. If so, please explain.
> >
> The condition Cthroughput will assure that the system will be able to
> handle
> all the events that physical system generates within the restraints given
> by
> this physical system.

Yes, but it is not enough in order to handle all events in any application if we allow asynchronous appearance of the events... Ditto for Ctimeliness.

Example:
n = 20,
Tmaxp(i) = 19,9 sec, 0<=i<20,
Tmaxd(i) = Tmind(i) = 1.0 sec, 0<=i<20,
Twander(i) = 0.0 sec, 0<=i<20,
h = 0.1
----------------------------------
I.e., Cdeterminism, Cthroughput and Ctimeliness hold true for h=0.1.
Question: Will all events be handled timely if all 20 events appear simultaneously?
Answer: No.

> The condition Ctimeliness will assure that each event will be handled
> within
> the restrictions given by the physical system. Cthroughput is a consequence
> of Ctimeliness, but I separated out both conditions for 2 reasons:
>
> a) to be able to force a certain "slack" in the system, i.e. the system is
> able to handle more events than the physical system because engineers are
> very good at using Occam's Razor, quite often ignoring the non-ignorable. I
> know, I'm an engineer!!!!!!
>
> b) reading Armin's mails, there may be some rope in letting a system handle
> the throughput, but not reach every deadline. This really gives me the
> willies, but I defer to people who may know more, or different things, than
> I do (the difference between a good solution and an optimum solution)
> <snip>

Because Cthroughput is a consequence of Ctimeliness, the elimination of Cthroughput means just simplification of the definition without losing of the value. So, I dare to make the suggestion -- eliminate Cthroughput.

> I decided not to use Vladimir's definition:
> n n
> sum Tmaxd(i) <= min Tmaxp(i)
> i=0 i=0
> as I feel this is too harsh. I don't think that there are many systems that
> can respond to ALL events within the maximum time to handle the most
> demanding event.

I don't pretend it is necessary. Moreover, it is not adequate condition for =all= real cases in order to consider a system intended to control as a control system... But if you will dig deeper (will try to make the condition less
harsh) the picture will fall to pieces that will be described by different conditions (i.e., you will have a "burst of complexity"). IMO.

Oh, yes, and there is the error - either n+1 is the number of events in Event or we ought to use i=1 instead i=0. (Simon, please, consider this as a sign of my attention to your letter,
but not as a display of my captious character :-)

> Hope this discussion continues. :-)

And after this discussion the interesting question would be:
Let there is a hypothetical system with Tmaxd(i)=0.0(0<=i<n) intended to control a process... Can we consider this system as a control system? (I think no. Do you? :-)

Best regards,
--
Vladimir E. Zyubin

(Originally posted Fri 08/07/1998)
At 21:10 06.08.98 -0700, Vladimir E. Zyubin wrote:
>Dear List,
>
>At Tue, 4 Aug 1998 11:52:27 -0400 Simon Martin wrote:
><snip>
>
>> >2. The 0.8 and 0.1 look very strange to me... why not
>> >0.79999(9) or 0.1111111(1)? or Why not e^-1 (1/2.718281...)? :-)
>> >
>> It's ok to define things, but in order to take decisions then we have to
>> some quantifiable measure. Where do we draw the line between hard and soft
>> realtime? This was just my first stab at some values for defining,
>> quantitively, not qualitively, when to consider a system real time, and
>> furthermore when it is hard real time or soft real time. The value for the
>> "harshness" factor must be set by someone who knows more than me and can
>> justify the values given, but I had to have a go!!!
>
>I think nobody can justify the values because there are no
>criteria (I don't see at least).

There are clear technology criterions like: time resolution, precision in meeting of deadlines and so on ...

> Where do we draw the line between hard and soft realtime?
> - IMO, the correct question would be: what is reason we have to draw this
line?
> What is value of the terms?

The question is: what criterions must be use to select the right tools to solve your control problems ?

For instance ... would you be able to test ALL operating systems to select ONE for real-time processing ?

> Especially, when there are so many
>orthogonal definitions. It was very demonstrative when your
>discussion with Mr.Steinhoff about "hard/soft real time systems"
>was ended by Mr.Steinhoff's sentence that he was speaking about
>hard/soft real time =operating= systems... I bet that words like
>"control" or "operating" could not allow us to get this
>curious situation.

An 'operating system' is a piece of software ...
a 'control system' consists of software and hardware which interfaces the real world ...
a 'control application' is a the sum of a control system and the controlled physical process. IMHO ... that's the common understanding of that terms.

Each part of control system must meet technology attributes to handle the
requirements of the controlled physical process.

My approach was to define some technological criteria in order to decide which of the so called RTOSes can be use for soft-realtime or hard-realtime control applications.

<snip>
>
>Because Cthroughput is a consequence of Ctimeliness, the
>elimination of Cthroughput means just simplification of the
>definition without losing of the value. So, I dare to make
>the suggestion -- eliminate Cthroughput.

I don't think so ... you can't be sure to meet all deadlines without the
appropriate throughput.

>> I decided not to use Vladimir's definition:
>> n n
>> sum Tmaxd(i) <= min Tmaxp(i)
>> i=0 i=0
>> as I feel this is too harsh. I don't think that there are many systems that
>> can respond to ALL events within the maximum time to handle the most
>> demanding event.

After a second thought ...I would use this definition as criterion whether a control system can meet all timelines or not ... but I would introduce a factor S for simultaneousness, because not all Tmaxp(i) can be active at the same time.


n n
S * sum Tmaxd(i) <= min Tmaxp(i)
i=0 i=0

n n
with S = max sum simul active Tmaxd(i) / sum Tmaxd(i)
i=0 i=0

('max sum simul active' is the maximum sum of Tmaxd of all groups
processes which can be active at the same time.)

or in other words ...

n n

max sum simul active Tmaxd(i) <= min Tmaxp(i)
i=0 i=0


If this condition is true ... we are _basically_ able to meet all deadlines.

But this tells us nothing about how exact the deadlines are met. My approach is to use the precision in meeting the deadlines for the
differentiation of hard and soft real-time OPERATING SYSTEMS.

[ clip ..]

&g