Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!dtgcube!ed From: ed@uunet!dtgcube (Edward Jung) Newsgroups: comp.sys.next Subject: Re: 64MB in cubes Message-ID: <1989Dec1.121628.432@uunet!dtgcube> Date: 1 Dec 89 12:16:28 GMT References: <4283@helios.ee.lbl.gov> <21301@uflorida.cis.ufl.EDU> <21736@brunix.UUCP> <21795@brunix.UUCP> <9374@batcomputer.tn.cornell.edu> <7163@pt.cs.cmu.edu> Distribution: na Organization: The Deep Thought Group, L.P. Lines: 30 In-Reply-To: avie@wb1.cs.cmu.edu's message of 1 Dec 89 05:11:54 GMT If the 4 MBit SIMMS are freezing up the machine, you might be interested in knowing about the ROM-monitor 'm' command. It displays the current memory configuration. You can generally get into the ROM monitor no matter what happens. It is documented in chapter 17 of the System Reference Manual, and is available on-line. You should also be certain that you are running System version 1.0 and have correctly installed the system and hardware. As far as the utility of 64 MB with the 68030... it depends on the breakdown of memory usage. If 80% of the memory is used by one process (say a large data processing application), than you are probably best off with a single processor (unless you have a parallel app). If you are loading 100 small processes that split up that memory and are not communicating with eachother too much, then you probably want to split the memory among multiple processors using, say, symmetric multiprocessing facilities, and, one would hope, a fast inter-CPU channel (or truly shared, low-overhead memory) for Mach ports to utilize. At the level of 64 MB, however, RAM probably ought to be a shared resource since it is unlikely to be used at capacity most of the time (for most people today). For MOST people. Note also that Mach is an unusually memory conserving Unix. -- Edward Jung The Deep Thought Group, L.P. BIX: ejung 3400 Swede Hill Road NeXT or UNIX mail Clinton, WA. 98236 UUCP: uunet!dtgcube!ed Internet: ed@dtg.com