Asri-unix.537 net.unix-wizards utcsrgv!utzoo!decvax!ucbvax!hpvax!sri-unix!mike@BRL Sat Jan 16 08:02:10 1982 Memory Disks In response to the letter from Randy King - We at BRL have been a very good customer of Dataram, with 3 BULK MOS and 1 BULK CORE memory systems installed (across a base of 5 machines). However, we have found them significantly more useful for filesystem disks than for swapping. Let me describe one of our configurations: BRL-BMD (3/29): 11/70, with 3 80-Mbyte Massbus disks, 4096 blocks of BULK CORE for the system root, 4096 of BULK MOS for /tmp, 1 RK05 for swapping, 1 RK05 for users, 1.5 Mbytes of 450ns CacheBus MOS. On this system, swapping runs 2 - 15 swaps/sec, with an average for a loaded system (30 - 35 users) of about 7/sec. Clearly the 15/sec is the maximum of an RK05, but... On the other hand, I sometimes may see 75 - 200 blocks/sec of I/O for the ROOT or /tmp disks. (BTW, we have 65 blocks of kernel buffer cache, and kernel inode caching). The effects of this configuration on system response have been significant. UNIXes are I/O hungry creatues. When our next Massbus Controler & 300 Mbyte disks come in a few weeks, I expect performance to increase even further. The load here is pretty evenly split: AOS, secretaries, DBMS stuff, F4P & F77 compiles and tests, lots of "C" compiles, 10-15 ED or EMACS users, etc, etc, etc. On our remaining systems, we are using the BULK MOS just for /tmp, which makes compilers and editors respond a lot better. Having fast random access memory for mere swap space is unlikely to help anything except systems with overabundant I/O, or 18-bit address space (like 34s and 45s). As soon as the dual V6/V7 filesystem code is finished, we plan to make an attempt to have "exec" sense when pieces of files (or whole files) happen to be contiguous, and doing direct DMA of the contiguous portions into memory. (There will be NO way to write files that way; it will be left to the good graces of ALLOC, and standalone disk compactors). On a system which may be doing 5 - 8 exec's/sec, fetching the individual pieces of programs is quite a drain on the I/O system. I realize that this sounds distasteful, but I think that this is the only good way to approach this. (On a similar subject, Bill Lindemann implemented direct DMA filesystem I/O, and found that the cost of doing the PHYSIO was about the same as going through the buffer cache, and copying out to user space. I use this as additional evidence that the exec stuff will make a real difference, as we will only have to do 1 physio for the program load, and save all the block copies). PDP-11's arn't dead yet! -Mike ----------------------------------------------------------------- gopher://quux.org/ conversion by John Goerzen 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.