Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!rpi!bu.edu!att!pacbell.com!pacbell!rtech!mtxinu!taniwha!paul From: paul@taniwha.UUCP (Paul Campbell) Newsgroups: comp.sys.next Subject: Re: Using the old 68030 board Message-ID: <668@taniwha.UUCP> Date: 17 Oct 90 19:01:42 GMT References: <287@heaven.woodside.ca.us> <52796@brunix.UUCP> <8986@helios.TAMU.EDU> Reply-To: paul@taniwha.UUCP (Paul Campbell) Organization: Taniwha Systems Design, Oakland Lines: 45 In article <8986@helios.TAMU.EDU> cnh5730@calvin.tamu.edu (Chuck Herrick) writes: >Actually, the source with the greatest potential for problems in a >multiple-processor-boarded cube would be likely to arise from the >following: > Which board is in control of the bus and when? >Several backplane/bus configurations have been designed from the >start to handle more than one processor board (VME, Futurebus 1 and 2, >and STD come to mind). A set of bus-master/bus-slave protocols are >designed into these buses from the very beginning, and these >protocols, when followed, prevent interboard interference. NuBus (and NextBus) both support multiple masters and correctly arbitrate between them (assuming everyone is playing by the rules), however bus arbitration times take two bus clocks (200nS on NuBus, 160nS on NextBus), with one CPU board in the system your CPU board is 'parked' on the bus (which means that each bus cycle can skip the arbitration times). With two bus masters in the system boards will tend to find themselves parked on the bus about half the time giving a 1 clock average penalty for bus transfers (80nS), with 3 processors it becomes 4/3 clocks average (107nS) etc Of course this assumes that bus cycles don't collide (ie one processor isn't waiting for the other), in this case the arbitration times are hidden behind the current transfer. I think that the net effect of this will be to slow the system down a lot when you put on two boards, things will continue at this rate until the bus becomes saturated at this point things will slow down at a slower rate. Of course none of this takes into account software, if you are only using the NuBus to talk to a framestore, and the software makes sure that no more one process is talking to it at anyone time then there's no problem. On the other hand if your CPUs are sharing their main memorys then on average every other cycle will have to go over the NuBus to access the other CPU's memory (if you put kernels on both of them its probably going to be more between 1 of 4 and 1 of 2), each time you access the other CPU's memory you stop it from accessing it (and your's too). This will cause saturation to occur much faster (in fact in this case using seperate NuBus RAM would really help). Paul Campbell -- Paul Campbell UUCP: ..!mtxinu!taniwha!paul AppleLink: CAMPBELL.P What most people don't realize is that those plastic cover slips that your 3 inch floppies come in are actually condoms for protecting your computer from harmfull computer viruses - practice safe computing ..... :-)