HTML version (much easier to read) are available at :
http://www.realtime-info.be/encyc/techno/publi/faq/rtfaq.htm
http://www.groupipc.com/rtfaq.htm
What is the purpose of this FAQ ?
What is the charter of comp.realtime?
Where should I ask questions about real-time
systems?
What is considered good net.etiquette
on comp.realtime?
What exactly is meant by real-time?
What is POSIX 1003.1b (formerly 1003.4)?
Where is it available?
What makes an OS a RTOS?
What is a good RTOS?
Books
Magazines
Other newsgroup and mailing lists
dealing with realtime topics.
Web Site covering realtime topics.
Is Windows NT (or windows 95) a Real-Time Operating
System?
Which methodology should I use to design a Real-Time
System?
Which programming language should I use to develop
a Real-Time System?
What kind of processor should I use for my Real-Time
System ?
What kind of bus should I use for my Real-Time System
?
What Mezzanine technology should I use ?
Where can I find informations related to real-time
products?
Where can I find informations about real-time
Conferences, Workshops and Tradeshows?
International organisation for standards?
International User and Manufacturer Groups?
Which Research Institute and Universities are
involved in the Real-Time field?
Free Real-Time Product lists
======================================================
The purpose of this FAQ is to give sufficient knowledge to a new user
in the Real-Time field and to serve as a reference to the engineer working
in this field. This FAQ gives an overview about each topic and refers to
other ressources (Internet, Publications, Company) for a more complete
information.
A companion posting to this one, "Comp.realtime: Welcome to comp.realtime"@message-id realtime_welcome@, complements this one by providing a concise
introduction to the group. Another posting, "Comp.realtime: A list
of real-time operating systems", @message-id realtime_list@, provides
references to available operating systems.
The charter of comp.realtime is to provide a forum for discussion of
both the theory and practice of real-time
computer systems. The group is
unmoderated; participation is open to all.
[If there was a formal charter for the newsgroup at the time of its creation,
we don't have access to it at the moment. Readers?]
Note that the listing in the canonical "newsgroups" file is:
comp.realtime Issues related to real-time computing.
Comp.realtime is certainly the place. However, if you are asking about
a particular real-time system, see below for a (possibly) better place
to start.
For topics that are only somewhat related to real-time systems, also consider
comp.arch and/or comp.os.misc. For instance, topics about bus-based computer
systems are best asked in comp.arch, or, if they're about the VMEbus, comp.arch.bus.vmebus.
Here are some etiquette reminders that will help us all to make the
group an ever-friendlier place:
-- Please, before posting, ensure that you've read the basic Usenet etiquette
guide in news.announce.newusers.
-- Please set the Followup-To: line in your post. This is especially true
if you are cross-posting. If you are requesting information, consider setting:
Followup-To: poster, and then summarizing the replies to the net.
-- When following up, please change the Subject: line if the subject has
really changed.
-- Some sites that receive comp.realtime are on branches of the net that
frown on overtly commercial announcements. These postings are welcomed
on comp.newprod and anywhere in the biz.* hierarchy. However, short offers
by vendors to provide further information by email are usually seen as
acceptable.
======================================================
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 systems.
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 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.
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 realtime OS's consist
of: 1003.1 (OS, process, filesystem and device API), 1003.2 (utilities),
1003.1b (realtime), and 1003.1c (threads). POSIX 1003.1d (which defines
some additional realtime 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.
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.
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.
======================================================
Several people recommended as a starting place the article "Tutorial
on Hard Real-Time Systems", edited by John A. Stankovic and Krithi
Ramamritham, IEEE
Computer Society reprint series, Computer Society order number 819.
Here are some other suggestions from various net.sources, in no order:
A. K. Mok, The Design of Real-time Programming Systems Based on Process
Models, in Proc. 1984 Real-Time Systems Symposium, Dec.1984, pp5-17.
E. Kligerman and A. Stoyenko, Real-Time Euclid: A Language for Reliable
Real-Time Systems, in TOSE, Sep. 1986, pp 941-949, vol SE-12.
A. Stoyenko, A Real-Time Language With A Schedulability Analyzer, Computer
Systems Research Institute, University of Toronto, Dissertation, Dec. 1987.
D. W. Leinbaugh and M.-R. Yamini, Guaranteed Response Times in a Distributed
Hard-Real-Time Environment, in TOSE, Dec.1986, vol SE-12.
H. Kopetz and A. Damm and Ch. Koza and M. Mulazzani and W. Schwabl and
Ch. Senft and R. Zainlinger, Distributed Fault-Tolerant Real-Time Systems:
The MARS Approach, in IEEE Micro, vol.9, Feb.1989, pp25-40.
Caxton Foster's "Real-Time Programming: Neglected Topics," despite
the title, is a very good introduction to the basic topics of real-time
control,
starting with simple things like interrupts and debouncing switches, all
the way through digital filters. It's a thin paperback (Addison Wesley
MicroBooks), and a (somewhat) experienced programmer can get through it
in a couple of days.
Vickery, C. Real-Time and Systems Programming for PCs. New York: McGraw-Hill,
1993. 604 pp. The thesis is that the development environment for real-time
systems is ideal for studying systems programming, too. After some introductory
material, the book deals exclusively with Intel's iRMX operating systems,
with particular emphasis on iRMX for Windows.
iRUG. Proceedings of the Intel Real-Time User's Group. Annual, back copies
available from iRUG, P.O. Box 91130, Portland, OR 97291, (800) 255-4784.
Annual conference proceedings dealing primarily with Intel's family of
real-time OSs, iRMX.
Lawrence, P. D. and Mauch, K. Real-Time Microcomputer System Design. New
York, McGraw-Hill, 1987. 568 pp.
The emphasis is on the design of I/O circuits and assembly language interfaces
for small microprocessors used for embedded systems.
Mellichamp, D. A. Real-Time Computing. New York: Van Nostrand Reinhold,
1983. 552 pp.
Twenty chapters by 11 authors on topics ranging from signal processing
to managing real-time computing facilities.
Burns, A. and Wellings, A. Real-Time Systems and Their Programming Languages.
Wokingham: Addison-Wesley, 1990. 575 pp.
Ada, Modula-2, and occam 2 are used throughout the book, which covers topics
ranging from basic programming techniques, fault tolerance, exception handling,
concurrency, resource management, and distributed designs.
Peter Desnoyers <mailto:peterd@merlin.dev.cdx.mot.com>sends along:
The classic reference in the area of timers is:
George Varhese and Tony Lauck, "Hashed and Hierarchical Timing Wheels:
Data Structures for the Efficient Implementation of a Timer Facility",
Operating Systems Review 21, no. 5 (Proceedings of 11th ACM Symposium on
Operating Systems), 1987.
Their results show O(1) times for insert and delete of 13 and 7 instructions
for one of the schemes, and decent performance with large numbers of outstanding
timers.
Books references in The
Online Real-Time Encyclopaedia(there is always a comment there) http://www.realtime-info.be/encyc/techno/publi/books.htm
J.E. Cooling, Software Design for Real-time Systems, SBN 0-412-34180-8,
published by Chapman and Hall.
Yann Hang Lee and C.M. Krishna, Readings in real-time systems,
ISBN 0-8186-2997-5, 1993, published by IEEE Computer Society Press.
Mathai Joseph, Real-Time Systems, University of Warwick, ISBN 0-13-455297-0,
1996, published by Prentice Hall Professional Technical Reference.
Krishna M. Kavi , Real-time systems, abstractions, languages and design
methodologies, ISBN 0-8186-3152-X, 1992, published by IEEE Computer
Society Press.
Phillip Laplante, Real-time systems design and analysis, an engineer's
handbook, ISBN 0-8186-3107, 1993, published by IEEE Computer Society
Press
David L. Ripps, An implementation guide to real-time programming,
ISBN 0-13-451873-X, 1989, published by Yourdon Press, Prentice-Hall Building,
now out of print!
Ken Shumate and Marilyn Keller, Software specification and design, a
disciplined approach for real-time systems, ISBN 0-417-53296-7, 1992,
published by John Wiley and Sons, Inc.
Another list of books with comments http://www.realtime-os.com/rtresour.html
List from The Real-Time Encyclopaedia http://www.realtime-info.be/encyc/techno/publi/magazine.htm
There are at least two other newsgroups devoted exclusively to a particular
vendor's real-time operating system:
news:comp.os.lynx The LynxOX real-time
operating system.
news:comp.os.os9 Discussions about the os9
operating system.
news:comp.os.qnx The QNX real-time operating
system.
news:comp.os.vxworks The VxWorks real-time
operating system.
news:comp.sys.harris The Harris NightHawk
& CX/UX & CX/RT operating systems.
Here are some other related newsgroups:
news:alt.industrial.computing
news:comp.arch Computer architecture.
news:comp.arch.bus.vmebus Hardware
and software for VMEbus Systems.
news:comp.os.misc General OS-oriented discussion
not carried elsewhere.
news:comp.robotics All aspects of robots
and their applications.
news:comp.sys.m68k Discussion about 68k's.
news:sci.engr.control The engineering
of control systems.
news:sci.engr.manufacturing
There are too many other newsgroups devoted to computer operating systems
that support some form of real-time scheduling to list here. The interested
reader is advised to check the "newsgroups" file on her or his
local machine.
There is a realtime-related mailing list for embedded computer systems
developers. It is not strictly real-time, but there is some overlap.
To subscribe, send your email address to mailto:embed-request@synchro.com.
A mailing list for discussions concerning the use of Futurebus+ now exists.
Appropriate topics include the design, implementation, integration and
operation of the hardware and software that are related to Futurebus+.
To
subscribe, send the one-line email message (in the body of the message,
not the header; the Subject line is ignored) as shown below to
mailto:majordomo@theus.rain.com.
subscribe fbus_users <your_email_address>
To get more information about the mailing list, send the one-line command
shown next to mailto:majordomo@theus.rain.com:
info fbus_users
The info page is automatically sent when you subscribe.
A mailing list intended for the discussion of topics relating to the pSOSystem
and other products of Integrated Systems Inc., Software
Components Group, has been started. Send articles to
mailto:psosuser@isi.com and administrative (subscription) requests
to mailto:listserver@isi.com. The
list administrator is Radek Aster who can be reached at mailto:raster@isi.com.
Dan Hildebrand <mailto:danh@qnx.com>has a posting listing a number of the embedded PC standards and further
references. If enough folks are interested, it's sufficiently detailed
enough to make a separate FAQ of its own.
Russ Hersch <mailto:sibit@datasrv.co.il>is now maintaining two _extensive_ FAQs about specific microcontroller
families, and one about microcontrollers in general. Here's the pointers:
Subject: 68hc11 microcontroller FAQ
Summary: This article is a collection of information sources on the Motorola
68hc11 line of microcontrollers.
Archive-name: 68hc11-microcontroller-faq
Posting-Frequency: monthly
Subject: 8051 microcontroller FAQ
Summary: This article is a collection of information sources on the Intel
8051 line of microcontrollers (and variants).
[He's working on the archiving of this one.]
Posting-Frequency: monthly
Subject: Microcontroller Primer FAQ
Summary: This article is a primer and general FAQ about microcontrollers.
[He's working on the archiving of this one.]
[Posting-Frequency: monthly, I think]
He also states that Tom Kellett is working on a FAQ on the PIC micro-controller
line, and adds that "hopefully, this will lead towards a much needed
collection of microcontroller FAQs."
The Real-Time Encyclopaedia
about everything you want to know about Real-Time (http://www.realtime-info.be)
E. Douglas Jensen Web
Site (http://www.realtime-os.com/rtresour.html)
Frank Miller Resource list http://www.cs.umd.edu/~fwmiller/etc/realtime.html
QNX sponsored Resource list http://www.cera2.com/realtime.htm
The RTC Group (http://www.rtcgroup.com)
Embedded Systems (http://www.embedded.com/net.htm)
VITA (http://www.vita.com)
GRoupIPC (http://www.groupipc.com)
A good collection of links (http://www.ifi.unizh.ch/groups/ailab/embedded.html)
======================================================
This question appears repeatedly in this news group. Here are the key
points:
- Despite a real-time class process, the Win32 API is not suitable
to be used for a Real-Time System:
1. Two few priorities for processes and threads
2. No priority inheritance mechanism
3. Some calls are synchronous with process from the Dynamic Class
- Despite a good interface to hardware for CLASSICAL applications, this
interface is not suitable to develop a Real-Time System:
1. Most of the job in a device driver is done at the DPC level. And most
COTS DD take too much time in the DPC.
2. The DPC problem could have been avoided by increasing the number
of DPC levels, but this is not the case.
3. Pentium Power Management interrupt can preempt your system for an unpredictible
amount of time (depending of the BIOS)
- Real-Time clock
There is a lack of programmable timer.
For a more complete view, look at article :
http://www.realtime-info.be/encyc/magazine/articles/winnt/winnt.htm
Some companies are now providing Real-Time Extensions to fill up the hole let opened by Microsoft. (cf the RTOS list)
At least you should use one. It is high time people are convinced of
the interest of building a house with the plan. It is very strange that
people still think that Software development is equal to writing or even
hacking code. There are at least three big classes of methodologies :
- The one related to Ada (Booch)
- The one based on data flows
- The OO Methodology (OMT)
One could add the formal approach too (SDL, MSC).
The choice will be based on the inhouse knowledge, level of education and
the client knowledge of software development. For each methodology you
have tools that are more or less good.
Of course you can choose to use assembler. You can always use tools
from the Ancient Age. Nevertheless it would be much better to use a higher
level programming language. Most of them will fit. The Ada Community will
always try to convince you their language is the best to use in any cases. Here
is not the news group to argue about this (news:comp.lang.ada
is THE place). Others will try to convince you to use an OO language.
Then you have to be carefull with the memory management unpredicitbility
(Is there a garbage collection ? Is it under the developpers control?).
The best solution is to avoid the use of dynamic object creation. Just
create them at startup. You have to know that the most used languages are
(in alphabetical order) :
Ada, C, C++ for realtime system development.
Most of the time small parts of the system are still written in assembler
(small parts of Device Driver).
CISC vs RISC: there has been a lot of discussion in the past about this
issue. Because of the high number of registers in a RISC processor, people
said the context switch was not compatible with realtime systems requirements.
This is not true as compilers can optimise the use of registers to reduce
the size of the context switch. A lot of points could be added here, but
as a conclusion we can say that both can be used for Real-Time System.
This FAQ is not the place to start a new war , but you can send any additions
to mailto:jcmon@rtusi.com.
PowerPC 60x versus 40x
The PowerPC 60x family is well suited for calculation, but to deal with
the external world (through Hardware Interrupt) the family 40x should be
prefered as the interrupt management is much more oriented to hardware
whereas in the 60x family it is more oriented to software.
VMEbus vs Compact PCI
Just remember these few things :
1. you can have 21 boards on the same VME bus.
2. you have 7 priority levels for Interrupting on the bus
3. you have 4 level to take the bus
4. last but not least: the installed VME bus based applications is huge.
The Compact PCI offers a bigger bandwidth, is based on a widely spread standard and the boards should be less expensive to produce (the interface chips are cheaper).
Other busses:
The choice is big : FutureBus+, Multibus, VXIbus, PCI, ISA, ...
The choice will depend on the type of application, the type of hardware
to use (price/performance) and the target maket.
Industry Pack, PMC, M-Module, S-Bus ...
For IP and PMC, a good place to look at is http://www.groupipc.com/
For M-Modules, CXC Modules, a good place to look at is http://www.vita.com/mezzprod/mezzdirindex.html
It should finally be noticed that the choice will depend on the type of I/O you deal with. If the key point is price, then IP or M-Modules is the answer, if performance is the key PMC or S-Bus Module should be choosen. Another point is the availability of the products: here PMC and IP is THE choice. They are much more widespread than any other. They are also supported by a usergroup organisation : GRoupIPC
Here the choice is huge and the standardisation efforts
still poor (but this is changing quickly):
PROFIBUS, BITBUS, WorldFIP, FIELDBUS, CAN, MIL-STD-1553, ATM, Reflective
Memory, ...
The choice will depend on the price (MIL-STD-1553 is quite expensive, ATM
also), on the availability of controllers, drivers, PLC, ...
======================================================
Product directories :
VME Products Directory http://www.vita.com/vmeprod/prodir.html
Industry Pack and PMC Products Directory http://www.groupipc.com/products/products.htm
Chips Products Directory http://www.xs4all.nl/~ganswijk/chipdir/
ULC Buyer's Guide http://www.cera2.com/ulc.htm
RTOS :
http://www.cs.arizona.edu/people/bridges/oses.html
http://www.realtime-info.be/encyc/market/rtos/rtos.htm
New Products :
http://www.vita.com/npgallery/npgallery.html
http://www.embedded.com/prod.htm
http://www.realtime-info.be/encyc/market/chronic/chronic.htm
http://www.realtime-os.com/rtresour.html#olconf
http://www.realtime-info.be/encyc/market/calendar/calendar.htm
List from Real-Time Encyclopaedia
http://www.realtime-info.be/encyc/techno/asso/standard/standard.htm
ANSI: American National Standards Institute (http://www.realtime-info.be/encyc/techno/asso/standard/organ's/ansi.htm)
IEC: International Electrotechnical Commission (http://www.realtime-info.be/encyc/techno/asso/standard/organ's/iec.htm)
IEEE: Institute of Electrical and Electronics Engineers (http://www.realtime-info.be/encyc/techno/asso/standard/organ's/ieee.htm)
ISO: International Organization for Standardization (http://www.realtime-info.be/encyc/techno/asso/standard/organ's/iso.htm)
OMG: Object Management Group (http://www.realtime-info.be/encyc/techno/asso/standard/organ's/omg.htm)
OSF: Open Software Foundation (http://www.realtime-info.be/encyc/techno/asso/standard/organ's/osf.htm)
X/Open (http://www.realtime-info.be/encyc/techno/asso/standard/organ's/xopen.htm)
List from Real-Time Encyclopaedia : http://www.realtime-info.be/encyc/techno/asso/user/user.htm
VITA VMEbus International Trade Association (http://www.vita.com)
GRoupIPC Association promoting Mezzanines Solutions (http://www.groupipc.com)
PICMG Association promoting the Compact PCI bus (http://www.picmg.com)
Profibus (http://www.profibus.com)
======================================================
Here is a link to a page discribing activities of Universities and Research
Institutes:
http://www.realtime-info.be/encyc/techno/research/research.htm
This list includes the following Universities and Research
Institures :
List of links to research centers http://www.cs.umd.edu/~fwmiller/etc/realtime/research.html
Here is a collection of links towards free products http://www.eg3.com/realxrto.htm
======================================================
The FAQs are posted every 4 weeks to comp.realtime, comp.answers, and
news.answers.
It is available in html format at :
http://www.realtime-info.be/encyc/techno/publi/faq/rtfaq.htm
http://www.groupipc.com/rtfaq.htm
They are also available for anonymous FTP on rtfm.mit.edu in pub/usenet/comp.realtime
(available soon again) :
Comp.realtime:_A_list_of_real-time_operating_systems_and_tools_(LONG)
Comp.realtime:_Frequently_Asked_Questions_(FAQs)
Comp.realtime:_Welcome_to_comp.realtime
For those without direct FTP access, there is also a mail-server. Address
a message to mail-server@rtfm.mit.edu; leave the subject blank and include
in the body: send help. It will return the instructions for proper use.
The following net.folks, among others, have contributed to this posting:
Martin Timmerman <mailto:mtimmerman@realtime-info.be>
Luc Perneel <mailto:lper@rtusi.com>
Sebastien Deleersnijder <mailto:seb@rtusi.com>
Thomas M. Breuel <mailto:tmb@best.com
>
Tim Chambers <mailto:tbc@col.hp.com>
Chuck Cox <mailto:chuck@synchro.com>
Peter Desnoyers <mailto:pjd@midnight.com>
Kevin Driscoll <mailto:driscoll@src.honeywell.com>
Kurt Fuchs <mailto:fs_fuchs@rcsw56.rcvie.co.at>
Milt Fulghum <mailto:fulghum@vss.fsi.com>
Donald Gillies <mailto:gillies@ee.ubc.ca>
Dan Hildebrand <mailto:danh@qnx.com>
Marcelo C Mourier <mailto:mmourier@atmsys.com>
David L. Oseas <mailto:doseas@americasttv.com>
Alan F. Perry <mailto:alanp@eng.sun.com>
David B. Stewart <mailto:dstewart@cmu.edu>
John Theus <mailto:john@theus.rain.com>
Alexander Vrchoticky <mailto:alex@vmars.tuwien.ac.at>
Christopher Vickery
Lee Brown
A. Lester Buck
David Hansen
Russ Hersch
Rob Lesieur
Dave Lunger
Special Thanks to the previous responsible for the FAQ, he has done
a great job :
Mark Linimon <mailto:linimon@lonesome.com>