Does “Realtime” Mean “On-Time?”

Not necessarily. Used in its computer context, “realtime” does not necessarily even mean fast.

Realtime is a technical term. The term applies to certain techniques for squeezing maximum “clicks” from computers and applying the power to whatever job happens to be most important at any particular moment.

Realtime is important because many jobs — such as communications, command & control, robotics — cannot be performed well, if at all, without realtime techniques.

Digital Equipment Corporation’s success on factory floors — and IBM’s failure — cannot be explained by the capabilities of their respective computer iron. Digital used realtime software, IBM did not. The result? Digital won the factory war, IBM suffered a rare defeat. Sperry’s mainframe success aboard US Navy ships — and IBM’s failure — is an earlier example. Sperry used realtime operating system software, IBM did not. More recently NASD boxed AMEX’s kite when it powered NASDAQ with realtime Tandem computers.

What distinguishes realtime software from non-realtime? First of all, realtime implies multiple jobs are going-on. (Computer jocks call the jobs tasks or processes). MS-DOS and Windows do only one job at a time and are not realtime. Networks based on MS-DOS, such as Novell, are not realtime. (Just to complicate matters, MicroNEX’s software is realtime, and multitasking, although it “looks-like” MS-DOS).

Multitasking alone does not confer realtime capability. Unix/Xenix and OS/2 are multitasking. But, neither is realtime. Both are therefore unsuited for process control applications such as numerical control, communications, and high volume point-of-sale. Realtime software handles certain core functions in a specific way.These functions include:

• process scheduling & control — processes lie dormant, eating-up no CPU power, until needed. Only when “brought to life” by a specific event do processes consume power. Each process has a priority. Critical tasks — such as servicing a phone line — take precedence over less critical tasks. Process scheduling and control in realtime systems is fundamentally different than in “time slice systems” such as UNIX, VMS and OS/2 which dole out blocks of CPU time whether the time is needed or not.
  
  
• event driven — processes are started and stopped by events. Events may be defined as anything (such as clicking a mouse) that can interrupt a CPU or the stopping or starting of another task.
  
  
• input/output — all I/O is dynamically buffered and interrupt driven. Polling is taboo.
  
  
• dystra queuing — queuing techniques developed by John Dykstra more than forty years ago are generally accepted as the most simple, most powerful way of performing process control functions. Dykstra techniques form the basis of most high performance realtime engines today.

Disney World’s application software schematic shows realtime concepts in action. To begin, the system is dormant. The computer waits around for something to happen. Suddenly a handheld computer sends data to one of three modems. A software program (process) called “com” springs to life. Until now, it consumed no CPU cycles. Because it has high priority, it stops other activity that may be running. Com grabs the data, puts it in a queue, and goes to sleep. The act (event) of placing data in the queue wakes-up another program (process) called audit. Audit looks-up room information and writes a transaction on an audit file and room file — and into a queue. Additional programs wake-up and go back to sleep as bills are computed and move along towards Disney’s hotel management computer.

All these activities take place, unseen, in the background. Modems are answered (twenty or more could be used if needed), disks click, printers print, Disneys’ hotel management computer is sent data. At the same time, intense human activity takes place in the foreground. Managers check status of hotel rooms, reassign staff, and prepare commission and sales reports. Clerks reorder products and balance inventory levels at multiple staging areas. Users are not aware of the background activity because each background task finishes in a few hundredths of a second — which allows foreground tasks to proceed without apparent interruption.

High performance computing requires a marriage between a realtime operating system and an application software designer who can exploit realtime capabilities. When done well, the results are awe inspiring. MicroNEX technology, for example, was used to receive and verify 600,000 Medicaid claims per week from 12,000 providers — on a single 386 PC.