Asri-unix.310 net.unix-wizards utzoo!decvax!ucbvax!menlo70!sri-unix!CSVAX.william@Berkeley Sat Dec 26 20:21:50 1981 Foreign Memory Problems >From menlo70!hao!pag Mon Dec 7 10:36:32 1981 Subject: Foreign Memory Problems Newsgroups: net.unix-wizards After lengthy performance analysis of our 11/70 UNIX, we determined that the biggest bottleneck was swapping (avg 5-10 swaps/sec, as much as 25 swaps/sec during heavy use). This sounds typical. You might want to meter swapin/swapout seperately BTW. We had 512KB of core memory, and decided to double it with an additional 512KB. Due to cost considerations we purchased a Plessy PM-SJ11 MOS memory system (which connects to existing DEC MJ11 core memory). So now our response is really great, right? WRONG! There has been a noticeable slowdown in overall response time. In fact, it is even slower in single user mode! (The file system checks take longer). Hmm. Ichecks usually are i/o bound. Perhaps you could run a cpu bound prog like "inc r0; br .-1" and an i/o bound program to see if it's some cache bus strangeness. Isn't the memory bus on a 11/70 a syncronous 32bit bus? How can it be delayed unless you are getting hundreds of memory error retrys (I thought that only happened between cache <-> cpu. It would show up in std DEC diagnostics). Could the cache be somehow disabled by the installation ? Or maybe there is a timing switch for either MJ or MS-11 operation, and you have it set backwards. Performance analysis indicates that the only real difference is that swapping has decreased to near nil, other factors (context switches, system calls, buffer hits, char and block i/o, interrupts) remain the same.In fact, the system is equally slow even if the new memory is not being used.So it has been bothering me to come up with an explanation for this strange behavior. Can anyone think of an explanation (hardware, hopefully)? The only software related problem I have encountered with additional memory and a V6 UNIX had to do with the memory allocation routines silently walking off the end of the coremap and modifying my inode table. I had assumed the bug was due to the local severely hacked V6, but it showed up in V7 again. It has been know to NOT crash systems and leave them in a confused state, but it does not sound like your problem. More details of complete memory system: 128KB DEC MJ11B core in one chassis 256KB Trendata/Standard Memories core (separate chassis) 128KB DEC MJ11B core in 2nd chassis 512KB Plessy PM-SJ11 MOS & terminators The order of the list is also the cabling order (ie, Trendata memory lies between two DEC boxes, and memory is terminated in Plessy box). Soon we will scope the system for memory cycle time, but haven't done that yet. Any insight into this problem will be greatly appreciated. Thanks, peter gross A local 11/70 here had problems running both core and semi boards in an old 11/70. I think they finally solved it by flushing the core boards entirely. Bill Jolitz. ----------------------------------------------------------------- gopher://quux.org/ conversion by John Goerzen of http://communication.ucsd.edu/A-News/ This Usenet Oldnews Archive article may be copied and distributed freely, provided: 1. There is no money collected for the text(s) of the articles. 2. The following notice remains appended to each copy: The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996 Bruce Jones, Henry Spencer, David Wiseman.