Consumer Real-Time Systems: Michael B. Jones

Existing hard real-time algorithms and systems are very successful at what they were designed to do: ensuring deterministic behavior for complex time-critical systems, given a fixed and enumerable set of real-time tasks, each of which has well-understood real-time requirements and behavior.

In recent years, a different class of "consumer real-time" applications and systems have begun to emerge. These systems are different than traditional hard real-time systems in several ways:

• The set of tasks to be scheduled is not fixed. New and independently authored applications, each of which have real-time requirements, may be concurrently run by users, just as traditional non-real-time programs are invoked on today's mainstream computing platforms.
• The resource needs of consumer real-time programs in isolation may be hard to characterize or be poorly characterized. When run concurrently, characterizing the aggregate behavior of such programs becomes nearly intractable.
• The target hardware platforms may have widely differing performance characteristics due to different processor speeds, cache architectures, memory sizes, I/O performance, graphics accelerators, etc.
• Consumers expect resource utilization near 100% while still appearing to operate predictably.
• These systems are expected to tolerate occasional or in some cases even frequent missed deadlines and still yield acceptable results.

This development presents both a challenge and an opportunity for the traditional real-time community. Thus far, I am disappointed at how little the lessons learned by the traditional real-time community have actually helped those building consumer real-time systems.

It's unclear to me whether this is a failure to communicate and broaden the lessons from the hard real-time systems or whether a deeper phenomenon is at work -- that the problems being solved are often fundamentally different. I'm beginning to lean towards the latter view.

In either event, I believe one of two things will happen:

1. The real-time community will broaden its scope to incorporate consumer real-time.
2. An alternate, consumer real-time community will develop that largely ignores the first.

I think we're already well on the way towards (2). I believe that the traditional real-time community is at a critical point where they need to decide whether (1) or (2) should occur.

Inaction will inevitably lead to the second outcome.

Citation information for this position statement.
ACM Workshop on Strategic Directions in Computing Research.
SDCR Real-Time Working Group page.
Michael B. Jones' home page.