Aucbvax.5599
fa.unix-wizards
utzoo!decvax!ucbvax!unix-wizards
Sun Dec 27 09:42:02 1981
Foreign Memory Problems
>From CSVAX.william@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.

-----------------------------------------------------------------
gopher://quux.org/ conversion by John Goerzen <[email protected]>
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.