*********************************************************************** 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 --- Ray Van Tassle 19 Nov 1982