Path: utzoo!mnetor!uunet!husc6!bbn!rochester!cornell!uw-beaver!uw-june!pardo
From: pardo@june.cs.washington.edu (David Keppel)
Newsgroups: comp.arch
Subject: Re: RISC != real-time control
Message-ID: <4792@june.cs.washington.edu>
Date: 28 Apr 88 17:35:30 GMT
References: <1521@pt.cs.cmu.edu> <1532@pt.cs.cmu.edu>
Reply-To: pardo@uw-june.UUCP (David Keppel)
Organization: U of Washington, Computer Science, Seattle
Lines: 22
Keywords: RISC, real-time


I talked with our local real-time guru, Alan Shaw, who said something
to the effect of (not an exact quote, but I'll try to get the message
across):

    Doing any kind of timing analysis is very hard.  You can't
    assume in your analysis that there's going to be bus contention 
    every memory cycle, or your estimated performance is going to
    look much worse than it ever will in practice.  What people
    really do is come up with reasonable figures based on the
    probability of there being N consecutive bus contention cycles,
    and make your timing analysis based on some number of contention
    cycles that will happen with a probability that is smaller than
    the chance of other catastrophic failure.

Note that this analysis is independent of RISC/CISC or almost
anything else.  The key point here is that you can measure and
estimate probabalistically, and in practice the failure rate
from other sources (e.g., hardware failures) will be the
dominant mode of failure.

	;-D on  ( Well it looked good when I closed my eyes )  Pardo