Foreign Memory Problems
utzoo!decvax!ucbvax!unix-wizards
utzoo!decvax!ucbvax!unix-wizards
Sun Dec 27 09:42:02 AEST 1981
>From CSVAX.william at Berkeley Sun Dec 27 09:28:34 1981
>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.
More information about the Comp.unix.wizards
mailing list