Windows NT, CLI and STI (NT and real-time)

(Originally posted Wed 08/12/1998)
When it comes to commercial solutions for hard real time operating systems there are two groups of solutions, self-hosted and development-target
systems. Self-hosted systems that can have run-time implementations that are ROM-able and priced accordingly are the best solution all round in my
opinion so long as the performance and packaging requirements are met.

We have some experience with Concurrent PowerMAX and this operating system meets all the requirements listed below. It runs on PowerPCs including the single and dual 300MHz PowerPC VME boards from Motorola. Timings are interrupt response of 5-12 microseconds (depending on the hardware) with jitters in the 10 microsecond range. Context switch is 35 microseconds worst case. Interrupt levels and process priorities etc. are 256. Take a look at:

http://www.ccur.com

>----------------------------------------------------------------------------
>-------------------------------------
>
> HARDWARE
>
> - supports different interrupt levels (priorities)
> - allows nesting of interrupts
> - CPU reacts fast to interrupts in the range from nano to micro seconds
>
> SOFTWARE
>
> - event driven management of all system resources
> - priority levels for interrupt processing (32 up to 256)
> - 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 50 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)


Peter Clout
Vista Control Systems, Inc.
1137 18th. St.
Los Alamos, NM 87544-3304
(505) 662-2484
FAX (505) 662-3956
http://www.vista-control.com

(Originally posted Thurs 08/13/1998)
On Wed, 12 Aug 1998, Armin Steinhoff wrote:
<snip>
> technology requirements for operating systems for HARD REAL-TIME
> applications
> -------------------------------
>
> HARDWARE
>
> - supports different interrupt levels (priorities)
> - allows nesting of interrupts
> - CPU reacts fast to interrupts in the range from nano to micro seconds
>
> SOFTWARE
>
> - event driven management of all system resources
> - priority levels for interrupt processing (32 up to 256)
> - 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 50 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)

A couple of thoughts:

1. The idea of the definition that reflects the
marginal ability of present-day technology is interesting enough.

2. It seems to me that the requirement "The
CPU clock friquency must be no less than..." has been omitted. IMO, this requirement could make the things a bit clear... On the other hand, in this case somebody could say that QNX installed on Intel486, 66MHz does not comply with the requirements for control application at all. I
personally would strongly disagree with his opinion... and in despite of the fact that formally he was right.

<snip>
> >> The question is: what criterions must be use to select the right tools to
> >> solve your control problems ?
> >
> > IMO, it depends on a given control problem:
> >reliability, maintainability, robustness, ergonomics,
> >ecology, economics, etc. Some of the criteria can be reduced
> >to accuracy problem. Some of the accuracy problems can
> >be reduced to so-called "real time problem" that can
> >be easily reduced to problem of execution efficiency...
>
> My problem is now ... what is execution efficiency ??

Execution efficiency problem, which appears only in digital systems, is the problem of providing of minimal time of execution of a given function only via proper programming.

As far as I remember, the words was first introduced by Mr. Griffin. So, Mr. Griffin's remarks and corrections of the definition would be greatly appreciated.

> >So, the "right" tool that provides solution of the problem does
> >not mean solution of a given control problem.
>
> Yes ... but it makes sure that you are basically able to solve the problem
> using that tool.

... but it does not make sure that you are basically able to satisfy all requirements for the control system. Therefore, the information is not sufficient (is notadequate => is not necessary everywhere)...

However, the _main_ circumstance is: the
receiving of the information does not assume any utilization of any now existent definitions of the words "real time". Let's keep in mind that the discussed problem is: the information can not be delivered by the words "real time" because the words can not be adequately defined.

> I would rely on a real hammer if I had to hammer some nails down ... but
> when the head of the hammer is made by pure marketing ... you will not be very successful =

Agreed in full. The suggestion: because the hammer is characterized as a one with the head that is made by pure marketing, the head ought to be changed... )) ... Sorry, I have occasionally cast a glance at the subject of this
thread.

<snip>
> > I don't think the adjectives "real time" can help
> >somebody to make the choice. For instance... the choice between QNX and NT. IMO, to show the advantages of QNX you
> >ought to use another terminology.
>
> Of cause ... real-time is only one aspect. There are many other buzz words
> like:
> scaleability at run time, foot print, reliabilty, POSIX, distributed
> architecture ... only to name some.

I admit that the words "foot print" mean shameful gap in my knowledge, but the other words are pretty recognizable... until somebody does not try to use the word "open" instead of the some of them. (Just to be on a safe side: I do know OMAC's definition)

> BTW ... I heard that WinCE is only reconfigurable by recompiling some
> system parts at assembler level. 20 years ago ... the old RSX OS from DEC
> used a similar procedure

Thanks for the interesting info. Conclusion: it is an old well-known solution to provide execution efficiency of software at the expense of structure (really, of maintainability and reliability)... Oh, yes, perhaps, it is not quite correct because N.Virth think that it is fatware
... but I am told MS has parallel solved the priority inversion problem. :-|

<snip>
> > Yes, and execution efficiency is not the main attribute always and
> everywhere.
>
> 'execution-efficiency' sounds as good as 'real-time' ... both connected
> buzz words seem to be very dangerous

Good joke... I hope the above definition has made the situation a bit clear. The words are intended just to indicate the well-known problem with a more or less acceptable way. IMO, the corresponding abilities of the tools can be expressed by concrete numbers, e.g., time of context switching for a given platform, connexion between time of context switching and quantity of parallel processes, time of conversion of
physical input(output) into the internal presentation... Obviously, all these times should be real (i.e., should have a theoretical or practical confirmation)

> >> My approach was to define some technological criterions in order to decide
> >> which of the so called RTOSes can be use for soft-realtime or hard-realtime control applications.
> >
> > But before, we have to define words "soft-/hard-
> >real time control application". I doubt it is possible...
>
> It should be possible to use the time constrains of the control application
> .. ?

Yes, to show this we need just one convincing example...

<snip>
> >statement "the quickly the better". By the way, I am not
> >sure that now we have an unified definition of 'events' and
> >'deadlines' for servo control systems ...
>
> IMHO ... at least these basic terms are clear defined.
>
> BTW .... are there any natural processes which take care about deadlines ?

I would like to look at the examples too...

Regards,
--
Vladimir E. Zyubin
mailto:[email protected]
Institute of Automation & Electrometry
Novosibirsk Russia

(Originally posted Fri. 08/14/1998)
>On Wed, 12 Aug 1998, Armin Steinhoff wrote:
><snip>
>> My problem is now ... what is execution efficiency ??
>
Vladimir E. Zyubin replied:

>Execution efficiency problem, which appears only in digital
>systems, is the problem of providing of minimal time of
>execution of a given function only via proper programming.
> As far as I remember, the words was first introduced
>by Mr. Griffin. So, Mr. Griffin's remarks and corrections
>of the definition would be greatly appreciated.
<clip>

The phrase "execution efficiency" was commonly used in the past in computer programming literature to refer to performing a software function in as few clock cycles as possible. Achieving this was considered to be one of the greatest expressions of the programmer's art. It was contrasted with "programmer efficiency" or "programming productivity" or some such similar
phrase which referred to minimising the man hours involved in writing the program even at the expense of having a slower program.
It is interesting to remember that not all that long ago, almost all serious volume commmercial applications which ran on PCs were written in assembly language. 'C' or other compilers produced programs which were simply too large and slow to be acceptable for products like word processors. However, in the case of more specialised, lower volume applications, high level languages were used to reduce the cost of
programmer man hours. Thus you had a trade off between program speed and program cost where the optimal solution was not the same for every situation.
Nowdays as microprocessors get faster the balance has shifted towards minimising the manhours involved in writing a program. Newer
programming languages or systems such as Java are designed with this in mind.

*******************
Michael Griffin
London, Ont. Canada
[email protected]
*******************

The CS field of computability defines Real Time (or Constant Time) using the following formal definiton:
RT={M|Exists(K)All(C)[STP(C,M,K)]
In other words, a Turing machine M is in the set Real-Time if there exists some limit K such that for all input tape configurations C the TM will have halted on that input by K steps.
Every "procedure" has an equivalent TM. Every "input" can be represented by some configuration C. So if a "procedure" will halt for every "input" by some predefined number of steps K, then it is considered to belong to the set of Real-Time.
For those wondering, the set RT is actually RE because the configurations are bounded by K.