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

A

#### Antoine PERRIN

(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

M

#### Mike Granby

(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
http://www.paracon.demon.co.uk

A

#### Armin Steinhoff

(Originally posted 05/27/1998)
Yes ...this is in general true. But most important is the handling of the DPCs ...

Armin Steinhoff
http://www.DACHS.net

D

#### Dick Caro

(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

B

#### Bill Code

(Originally posted Wed 05/27/1998)
I ask the same question as Mike, I think all operating systems require sections of non-interruptable code. Operating systems have this feature in order to guarantee atomic access to critical data structures. The designers of the operating system will have paid close attention to keeping the non-interruptable sections very short, i.e. a few machine instructions.
Bill Code
MPM Engineering Ltd.
4-6240 202nd St., Langley, B.C., Canada, V2Y-1N2

V

(Originally posted Thu 05/28/1998)
Dear Antoin,
It seams to me, Windows NT is a typical hard real time OS ;-) And your goal is just to decrease ‘maximal response time’/ to increase ‘maximal possible frequency of the events’.
Good luck,

mailto:[email protected]
Institute of Automation & Electrometry
Novosibirsk Russia

Any control system is ‘hard real time’... by definition.

D

#### Dale Ross

(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

S

#### Shields, Lester R

(Originally posted Thu 05/28/1998)
Interrupt Service Routines (ISRs) usually contain short blocks of non-interruptible code. In fact, interrupts are usually disabled during the processing of parts of the ISR. Depending on the computer architecture, the disabling of interrupts may be done by the hardware or may be left to the ISR. In either case, the ISR must reenable interrupts after a few instructions. Usually, the architects of the OS will specify the maximum time that interrupts may be disabled. For example, I believe DEC specs said that in RSX-11M, an ISR could only leave interrupts disabled for 100 microseconds.
Sections of the OS requiring atomic access to data structures can usually be handled by single-threading such sections of the OS and queuing access to these data structures. Since these structures are (or should be) only accessed through these single-threaded code sections, this code can be interrupted. In this case, the ISR is not permitted access to kernel data structures except through the queued requests.
Or at least that’s how I think I remember it!
Les

M

#### Mike Granby

(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
http://www.paracon.demon.co.uk

M

#### Mike Granby

(Originally posted Thu 05/28/1998)
Perhaps I should have indicated that my question was rhetorical—I agree with what you’re saying about OS structure, although I would say than from my experience it is not always possible to rely on critical sections and other mutex devices within kernel code, and that in some circumstances non-interruptability is the only option.

Mike Granby
http://www.paracon.demon.co.uk

D

#### Dick Caro

(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

V

(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,
mailto:[email protected]
Institute of Automation & Electrometry
Novosibirsk Russia

D

#### Dick Caro

(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

V

(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?
With kind regards,

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)

E

#### E. Douglas Jensen

(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
[email protected]
http://www.realtime-os.com

V

(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,

mailto:[email protected]
Institute of Automation & Electrometry
Novosibirsk Russia

A

#### Antoine PERRIN

(Originally posted Fri 06/26/1998)
Dear group,
Perhaps, the solution to the problem of “real-time” should be solved by using an other vocabulary. Recently, I read a book where the authors make the distinction between:
&#61623; closed system i.e a system that only interract with the user and is not influenced by external physical constraints (these constraints can be time considerations). Of course, from this point of view, the human operator is a very tolerant physical system ;
&#61623; open system i.e a system that must take in account the constraints of an external physical system on which it operate.

Antoine PERRIN

V

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

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:[email protected] Institute of Automation & Electrometry Novosibirsk Russia R #### Rufus (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
> 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

L

#### Lester R. Shields

(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.