Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site calgary.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!ihnp4!alberta!calgary!radford
From: radford@calgary.UUCP (Radford Neal)
Newsgroups: net.works,net.micro.16k
Subject: Speed of 32016 with wait states.
Message-ID: <969@calgary.UUCP>
Date: Tue, 12-Feb-85 15:00:25 EST
Article-I.D.: calgary.969
Posted: Tue Feb 12 15:00:25 1985
Date-Received: Thu, 14-Feb-85 02:47:38 EST
References: <357@topaz.ARPA> <320@terak.UUCP> <278@petrus.UUCP> <5040@utzoo.UUCP> <2347@nsc.UUCP>
Organization: University of Calgary, Calgary, Alberta
Lines: 17
Xref: watmath net.works:912 net.micro.16k:203

> >Another relevant question is, does your memory have zero wait states?
> >People I trust tell me that the 32016's performance deteriorates
> >*SHARPLY* when wait states are introduced -- it's much worse than
> >you would expect, and in particular it's not linear in the number of
> >wait states.

If the systems' performance deteriorates more than linearly with wait
states I think something other than the chip is at fault. The only thing
I can think of is that fixed interval interrupts are occuring (e.g. a
regular 100/second timer interrupt, or regular serial line or mouse
interrupts). If the interrupts are already taking 50% of the CPU, doubling
memory access time can make the system infinitely slower. We have a 68000
system which appears to go an order of magnitude slower when run with only 
moderately slower memory for this reason.

    Radford Neal
    The University of Calgary