Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site rtech.UUCP Path: utzoo!watmath!clyde!cbosgd!ihnp4!nsc!amdahl!rtech!daveb From: daveb@rtech.UUCP (Dave Brower) Newsgroups: net.arch Subject: Re: Memory Law Message-ID: <746@rtech.UUCP> Date: Sat, 16-Nov-85 04:54:17 EST Article-I.D.: rtech.746 Posted: Sat Nov 16 04:54:17 1985 Date-Received: Mon, 18-Nov-85 05:13:09 EST References: <764@bu-cs.UUCP> Organization: Relational Technology, Alameda CA Lines: 34 > Sooooo....I have been trying to come up with a reasonable rule of thumb > for how much memory is too much (?!) It will go something like this: > > Don't buy more memory than your CPU can zero out in N seconds. There's handwaving here that comfy values are between 5 and 8 Meg/mip. Any less and you're plainly memory starved, and above that you may get diminishing returns. A maxi-memory opinion is put forth by Steve Wallach in this month's Unix Review. He's talking about 100M systems: "Do you really have to have all that memory? Yes, even for UNIX. ... With all this physical memory, we can make the disk cache as big as we like, so when we run up against I/O benchmarks, we just define a disk cache large enough to keep us from ever having to go to disk. ... Some people cry, 'Foul! That's not a fair benchmark because I can't do that on my VAX'--to which, of course, we respond, "Right." Then we smile and don't say anything more." The problem with this is that it doesn't represent very many real job mixes. On a 750 with 8 meg you're probably running out of gas in the CPU, which is where Barry's N sec to clear comes in. You probably also need to take into account the I/O bandwidth. 370-ish systems seem to be able to handle more memeory than the CPU speed would indicate because of the bandwidth available with the channel I/O. Remember when 1k S100 cards were $400? -- {amdahl|dual|sun|zehntel}\ | {ucbvax|decvax}!mtxinu---->!rtech!daveb | "Something can always go wrong" ihnp4!{phoenix|amdahl}___/ |