README.md
***********************************************************************
Turn your excess main memory to a semiconductor "disk".
Ray Van Tassle
Motorola
1301 E. Algonquin Rd.
Room 4135
Schaumburg, Ill.
(312)-576-6017
We recently upgraded our program development 11/70 (running RSX-11M v3.2)
from 256KW to 2 MW, and added many
more terminals at the same time. Before, when more than 6-8 users
were logged on doing program development, the system would swap itself
to death. We quadrupled our memory (and went from core to MOS), which
took care of that, but now the system slowed down noticably when more
than 10-12 users, especially when several of them were running TKB.
I looked at the RMD memory display and saw all the empty memory, then
at the DA (device activity) page and saw all the disk I/O active
and queued up (our main disks are one RP-04 and two RP-06's, all on the
same controller).
Now, we have been using Ralph Stammerjohn's Virtual Disk package for several
years, and I have always admired his statement, "Look, a disk is just
a bunch of contiguous block, right?"
So when I saw all that empty memory, I thought about it, and suddenly
realized that I was really looking at a bunch of contiguous block, they
just didn't have a device driver hooked up to them. So I sat down and
over the week-end, wrote a device driver (stealing as much as possible
from VDDRV), and called it FX (Fixed Disk).
Now disk accesses to FX: involve a core-to-core (should that be
MOS-to-MOS??) move, which is a whole lot faster than a disk seek and
read.
Needless to say, the performance of our system has improved greatly. We
regularly have 13-20 terminals logged on, doing program development,
and get the same performance we used to have with half the number of
active terminals.
---------------------------------------------------
The way it works is this: Create a partition named "FXDISK", this is
the semiconductor memory. When you load the driver, it looks for this
partition, and sets the number of blocks in the disk (U.CW2/U.CW3)
according to the size of the partition. Then you do the normal things
to the disk--BAD, INI, MOU, etc.
I allocate 256KW, which gives 1024 blocks. This is not really large
enough to use as a scratch disk for work files (for MAC and TKB), and
we have enough memory that we rarely do much task checkpointing.
So I put the most commonly used task images on FX: and install them
from it. For us, these are MAC, TKB, CCL, INS, PIP, SYS (the multi-user
part of MCR---...MCR), and TECO.
I also put two heavily used OLB's there, SYSLIB.OLB and the C OLB.
I zapped TKB so that it defaults to FX:[1,1]SYSLIB.OLB rather
than LB:[1,1]SYSLIB.OLB. See BIGTKB.DUM for help in finding where to
put the patch.
Task-builds are still not blindingly fast
(they will probably never be), but one particular task-build dropped
from 2 minutes to 35 seconds (!!) on an unloaded system.
------------------------------------------------------
I have included the command files we use. LOADFX.CMD is invoked
from [1,2]STARTUP.CMD.
I see no reason why this wouldn't also work on M-PLUS, you should
only have to fix up the FX data-base, which shouldn't be hard to
do.
-------------------------------------------------------
After further thinking (along with some nudges from other sources), it
seems to be that I could also write a disk-block cacher, using
the same move logic as FXDRV, and another memory partition.
The coding should not take longer than a week-end, but the investigation
to pick the cache replacement algorithm and cache size will
take considerably longer. The BITMAP.SYS on my RP06 is 85 blocks--
I wonder how much it is accessed.
-------------------------------------------------------
I get dizzy thinking of all the weird things you could do---
imagine a virtual-disk on an fx memory-resident disk---
or caching blocks of a FX disk---
or caching blocks of a virtual disk on a fixed-disk---
or ---