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