Here are Victor Yodaiken's answers:

• What is real-time? . . . and . . . What is hard real-time? — Real-time software can meet timing deadlines. Then there is “soft”, “firm”, “usually”, or “most of the time” or “kind of” real-time. These all seem to be ways of saying “not” real-time. The term “hard” is sometimes used to try to distinguish software that really is real-time from these various not really real time types of things.

  RTLinux is a hard real-time operating system. We can characterize the system in terms of the worst-case delays between interrupts and start of interupt handling software and the worst case jitter in realtime threads that run periodically. Operating systems that offer “typical” interrupt response times are not hard realtime. Consider what happens if a chip is “typically” placed in the right place on a circuit board or an E-commerce transaction is “usually” restarted on a failure before the network can time out, or a rocket motor “almost always” shuts down fast enough when an abort sequence is started.

• Who needs real-time? — I'll stick to real real-time, and not worry about the other kinds. You need real-time if you want to control machinery (including communications equipment) that behaves poorly when software misses deadlines. Many types of systems can tolerate missed deadlines and in most cases average case (typical) performance is more imporant than worst case. For example, TCP is an inherently non-realtime protocol. But a robot arm goes out of position if signals come late, and it does not correct if you make the next couple of signals come early. And think about the failure detection in a cluster of computers connected by a network. If the network message system is realtime, you can detect a failure if a “heartbeat” message does not show up after a fixed interval: perhaps detecting failure in milliseconds instead of seconds. While computers are getting faster all the time, demands on computers are getting more exacting. A modern PC does not need real-time software to act as an ordinary 10BaseT router, but routing in a fault tolerant switch serving voice-over-IP is something else. Gigabit Ethernet can produce a packet every 1.5 microseconds and if you start being serious about exploiting this for industrial control or video serving, you better have software that can guarantee to not drop packets — ever.

• What is “soft real-time”? — Another kind of “not” real-time. Some real-time systems can tolerate a certain level of failures and these are sometimes called “soft” realtime systems. For example, consumer video display can tolerate dropped frames now and then. Note, however, that there is a big difference between real-time QoS systems that can tolerate some level of failure but have absolute realtime limits and soft real-time that does not have to meeting deadlines. If there is a skip in a consumer video now and then, nobody will notice, but if you drop 5 packets in a row in a professional audio system, you may have ruined a recording.

• How should real-time performance be characterized? — Real-time performance should be characterized by worst case interrupt response times and worst case periodic jitter. Measures of how many events/time can be processed are also useful.

---

Panelist's bio: Dr. Victor Yodaiken is President of FSMLabs, a software development company headquartered in New Mexico and with developers in the US and Europe. Dr. Yodaiken is the creator of RTLinux. He has been working on operating systems in both industry and academia since the early 1980s when he was one of the developers of one of the first commercial distributed fault tolerant UNIX systems.

 
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.