Foreign Memory Problems

[utzoo!decvax!ucbvax!menlo70!sri-unix!CSVAX.william at Berkeley]

	>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.