Here are Jim Ready's answers:

• What is real-time? — The right results on time.

• What is hard real-time? — The right results late are wrong.

  The quantitative definition of “on time” is completely set by the external requirements of the system. It can be nanoseconds, microseconds, or days — but it is whatever the system requires for correct operation. Hard real-time systems consider the late delivery of correct results as a system failure. Classic examples are control systems, such as those used on aircraft, where both the correctness of the results and their timely delivery must occur for the aircraft to operate safely.

  MontaVista is dedicated to producing a hard real-time pure Linux solution. Our prototype work with the preemptible kernel is the first major step in that direction.

• Who needs real-time? hard real-time? — Many systems require real-time response from a computer. The correct delivery of audio and video requires that the bits be output within certain time constraints or the user will see or hear glitches in the results. The most pleasing results are when no deadlines are missed and thus multimedia can be considered hard real-time, if an unsatisfied user is considered a failure.

• What is soft real-time? — The right results late are of less value than the right result on time, but do not constitute “system failure”.

• How do you characterize real-time performance? (That is, what key specifications should RTOS vendors use to objectively characterize their performance?) — In order to objectively characterize a real-time operating system, the users need to know some key measurements. The key measurements are:
  
  
  • Worst case interrupt disable time: The maximum duration that interrupts are disabled by the operating system, device driver or user software.

  • Worst case interrupt dispatch times: The maximum time from the processor recognizing the interrupt to the first instruction in the interrupt handler. There may be multiple such measurements, for different types of interrupt handlers, each with more or less capability.

  • Worst case kernel non-preemption time: The maximum duration that the kernel disables preemption of the running process to switch to a higher priority executable process.

  • Worst case process response time: The maximum time from a process schedule event (whether generated via a hardware interrupt or a software event) in the kernel to execution of the first instruction in the process.
  
  Note that these definitions are not crisp enough to ensure “apples-to-apples” measurements across different systems, but they are good starting points for formalizing precise measurements.

---

Panelist's bio: MontaVista President/CEO Jim Ready is a recognized authority in the Embedded systems and real-time software industry. With over 25 years of technical and entrepreneurial experience, he pioneered the development of the first viable commercial RTOS product, the VRTX real-time kernel while co-founder of Ready Systems. In 1993, Ready Systems merged with Microtec Research, went public in 1994, and was acquired by Mentor Graphics in 1995. During this period Jim served as Ready Systems' President, and as CTO at Microtec/Mentor. Jim founded MontaVista in 1999 to bring the Linux operating system to the embedded systems market.

 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.