Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!nstn.ns.ca!news.cs.indiana.edu!samsung!spool2.mu.edu!uwm.edu!src.honeywell.com!klemmer!vestal
From: vestal@SRC.Honeywell.COM (Steve Vestal)
Newsgroups: comp.arch
Subject: Re: Real Time/Cache
Message-ID: <1991Jan28.174243.17814@src.honeywell.com>
Date: 28 Jan 91 17:42:43 GMT
References: <11190@pt.cs.cmu.edu> <90331.001007DXB132@psuvm.psu.edu> <11228@pt.cs.cmu.edu> <17999@cbmvax.commodore.com>
Sender: news@src.honeywell.com (News interface)
Organization: Honeywell Systems & Research Center
Lines: 27
In-Reply-To: jesup@cbmvax.commodore.com's message of 24 Jan 91 02:37:51 GMT
Nntp-Posting-Host: klemmer.src.honeywell.com

In article mumble jesup@cbmvax.commodore.com (Randell Jesup) writes:

>> 	The cache does nothing for you in a realtime application since you
>> have to assume worst-case anyways (well, not nothing, but not far from it -
>> non-realtime tasks on the same machine might get an advantage).

My sympathies lie with Randell, but things aren't always this dire.

First, it has been argued that some real-time code is sufficiently
deterministic (i.e. memory access patterns are largely independent of input
data) that cache behavior will be largely deterministic.  Even if they can't
be easily predicted from an examination of the code, execution time
measurements taken during sample executions are representative of true
worst-case execution times.

Second, even though missing a deadline is a fault, this needn't be a fatal
fault in all cases.  There are scheduling techniques that can allow some
applications to tolerate occasional timing faults.

My impression is that most hardware/software trade-off studies have assumed
that the goal was to maximize average throughput.  This is not the same goal
as minimizing verifiable upper bounds on execution time, which is desirable
for safety-critical real-time applications.

Steve Vestal
Mail: Honeywell S&RC MN65-2100, 3660 Technology Drive, Minneapolis MN 55418 
Phone: (612) 782-7049                    Internet: vestal@src.honeywell.com