● Comp.realtime FAQ 3(转寄) - 荔园在线 | 深圳大学学生论坛,荔园晨风BBS,深大在线网站

荔园之美，在春之萌芽，在夏之绽放，在秋之收获，在冬之沉淀

发信人: georgehill (人生不定式), 信区: Linux
标  题: Comp.realtime FAQ 3(转寄)
发信站: BBS 荔园晨风站 (Sat Sep 16 15:01:30 2000), 站内信件

【以下文字转载自 georgehill 的信箱】
【原文由 georgehill.bbs@smth.org 所发表】
发信人: hhuu (什么是水，就是water啊), 信区: FreeBSD
标  题: Comp.realtime FAQ 3(转寄)
发信站: BBS 水木清华站 (Sat Sep 16 00:23:52 2000)

======================================================
II- DEFINITIONS
------------------------------
   What exactly is meant by real-time?

There are _several_ definitions of real-time, most of them contradictory.
Unfortunately the topic is controversial, and there doesn't seem to be 100%
agreement over the terminology.

1. The canonical definition of a real-time system (from Donald Gillies
mailto:gillies@ee.ubc.ca ), is the following:

"A real-time system is one in which the correctness of the computations not
only depends upon the logical correctness of the computation but also upon
the time at which the result is produced. If the timing constraints of the
system are not met, system failure is said to have occurred."

Others have added:

"Hence, it is essential that the timing constraints of the system are
guaranteed to be met. Guaranteeing timing behavior requires that the system
be predictable. It is also desirable that the system attain a high degree of
utilization while satisfying the timing constraints of the system."

A good example is a robot that has to pick up something from a conveyor
belt. The piece is moving, and the robot has a small window to pick up the
object. If the robot is late, the piece won't be there anymore, and thus the
job will have been done incorrectly, even though the robot went to the right
place. If the robot is _early_, the piece won't be there yet, and the robot
may block it.

Another example is the servo loops in an airplane when on auto-pilot.
The sensors of the plane must continuously supply the control computer with
proper measurements. If a measurement is missed, the performance of the
airplane can degrade, sometimes to unacceptable levels.

David Sonnier  ( mailto:dps@devnull.mpd.tandem.com ) adds the distinction:

In the robot example, it would be hard real time if the robot arriving late
causes completely incorrect operation. It would be soft real time if the
robot arriving late meant a loss of throughput. Much of what is done in real
time programming is actually soft real time system. Good system design often
implies a level of safe/correct behavior even if the computer system never
completes the computation. So if the computer is only a little late, the
system effects may be somewhat mitigated.

2. One will occasionally see references to "real-time" systems when what is
meant is "on-line", or "an interactive system with better response time than
we used to have". Often, this is just marketing hype. For instance, although
some have queried whether running "rn" is real-time, it is not, as it is
interacting with a human who can tolerate hundreds of milliseconds of delays
without a problem. Similarly, on-line stock quotation systems interact with
humans.

3. One will also see references to "real-time" systems when what is meant is
just "fast". It might be worth pointing out that "real-time" is not
necessarily synonymous with "fast"; that is, it is not the latency of the
response per se that is at issue (it could be of the order of seconds), but
the fact that a bounded latency sufficient to solve the problem at hand is
guaranteed by the system. In particular, frequently, algorithms that
guarantee bounded latency responses are less efficient overall than
algorithms that don't.

4. One will also occasionally see discussions of "soft" vs. "hard" real-time
systems. In many of these discussions, "hard" real-time means the type of
real-time system discussed above, and "soft" real-time means systems which
have reduced constraints on "lateness" but still must operate very quickly
and repeatably. However, the definition is controversial, as some mean by
"hard" and "soft" the degree of time constraints. For instance, a real-time
process attempting to recognize images may have only a few hundred
microseconds in which to resolve each image, but a process that attempts to
position a servo-motor may have tens of milli-seconds in which to process
its data.

5. Robert Bristow-Johnson adds the following distinction (in the case of
DSP):
In a real-time DSP process, the analyzed (input) and/or generated (output)
samples (whether they are grouped together in large segments or processed
individually) can be processed (or generated) continuously in the time it
takes to input and/or output the same set of samples independent of the
processing delay.

Consider an audio DSP example: if a process requires 2.01 seconds to analyze
or process 2.00 seconds of sound, it is not real-time. If it takes 1.99
seconds, it is (or can be made into) a real-time DSP process.

A common life example I like to make is standing in a line (or queue)
waiting for the checkout in a grocery store. If the line asymtotically grows
longer and longer without bound, the checkout process is not real-time. If
the length of the line is bounded, customers are being "processed" and
outputted as rapidly, on average, as they are being inputted and that
process _is_ real-time. The grocer might go out of business or must at least
lose business if he/she cannot make his/her checkout process real-time (so
it's fundamentally important that this process be real-time).
The last definition (5) is the one used for real-time audio and video, for
phone call over Internet, and so on. It means that the processing time is
less than the time to get a sample. Note that in the case of Internet it is
easy to get starvation because the sample arrivals depend on the bandwidth.

------------------------------
   What is POSIX 1003.1b (formerly 1003.4)? Where is it available?

POSIX 1003.4 was the working name for what is now the 1003.1b standard..

Recently, Dan Hildebrand posted:

The ratified POSIX standards that generally pertain to real-time OS's
consist of: 1003.1 (OS, process, filesystem and device API), 1003.2
(utilities), 1003.1b (real-time), and 1003.1c (threads). POSIX 1003.1d
(which defines some additional real-time extensions like standardized
interrupt handler support) is not yet ratified, although some OS's already
support portions of it.

The best way to get the most current status is to refer to some of these
texts and contacts:
The POSIX 1003.1 standard is ISBN 1-55937-061-0. A good O'Reilly text is
"POSIX Programmer's Guide: Writing Portable UNIX Programs". Donald Lewine.
ISBN: 0-937175-73-0

For other standards, the IEEE's address is:
Secretary, IEEE Standards Board
445 Hoes Lane
P.O. Box 1331
Piscataway, NJ 08855-1331
USA
http://cs-www.bu.edu/pub/ieee-rts/Home.html
Many of the POSIX draft standards can also be obtained by calling the IEEE
Draft Standards Office. Credit card in-hand, phone +1 202 371 0101 to place
an order.

Another contact is the IEEE-USA Customer Service Center at 800 678 4333
(+1 908 981 1393 for outside of 800 zone); fax: +1 908 981 9667.

------------------------------
   What makes an OS a RTOS?

1. A RTOS (Real-Time Operating System) has to be multi-threaded and
preemptible.
2. The notion of thread priority has to exist as there is for the moment no
deadline driven OS.
3. The OS has to support predictable thread synchronisation mechanisms
4. A system of priority inheritance has to exist
5. OS Behaviour should be known
So the following figures should be clearly given by the RTOS manufacturer:
1. the interrupt latency (i.e. time from interrupt to task run) : this has
to be compatible with application requirements and has to be predictable.
This value depends on the number of simultaneous pending interrupts.
2. for every system call, the maximum time it takes. It should be
predictable and independent from the number of objects in the system;
3. the maximum time the OS and drivers mask the interrupts.
The following points should also be known by the developer:
1. System Interrupt Levels.
2. Device driver IRQ Levels, maximum time they take, etc.

------------------------------
   What is a good RTOS?

A good RTOS is not only a good Kernel ! A good RTOS should have a good
documentation, should be delivered with good tools to develop and tune your
application. So even if some figures like the Interrupt latency, Context
switch time are important, there are a lot of other parameters that will
make a good RTOS. For example a RTOS supporting many devices will have more
advantages than a simple very good nano-kernel.

------------------------------
What is RMA?
   "Rate-Monotonic Analysis" is a term coined by researchers at CMU. It
refers to the real-time performance analysis of a system design that uses
static-priority driven scheduling, in particular, the "rate-monotonic"
static priority assignment, where tasks with shorter periods get the higher
priorities, in a typical static-priority driven real-time operating system
like pSOS VxWorks VRTX etc.
Research (mostly) from CMU and U-York and Illinois gives you the
mathematical tools to answer "what if I designed it this way???" analysis on
your system workload. You need to break your software into "tasks" with
"periods" and "deadlines" (relative to the period) and you must be able to
guess or prototype a rough "execution time" for each task. Also, for more
precise analysis, it helps to know all the critical sections and their
runtimes and who shares them, or at the least, the length of the longest
critical section in all of your software.
You can plug all this data into a "schedulability analyzer" tool (PERTS,
MIMOSA, Scheduler 1-2-3 (CMU), Software Engineer(?s) Notebook (CMU, newer)),
or even the back of an envelope "Utilization Test" or "Formula Test" and
find out if your workload will meet all its different deadlines.
If you workload does not meet deadlines, the better tools can help you to
explore changes to your workload, in order to meet all the deadlines.

--
  行列中        作不朽文章
  谈笑间        论古今英雄
  痴狂里        诉红尘情爱
  来去时        不枉一生风流
                        ---------  bbs.ntu.edu.tw

※ 来源:·BBS 水木清华站 smth.org·[FROM: 166.111.161.33]
--
※ 转载:·BBS 荔园晨风站 bbs.szu.edu.cn·[FROM: 192.168.1.115]

荔园在线首页友情链接：深圳大学深大招生荔园晨风BBS S-Term软件网络书店