Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!mit-eddie!genrad!decvax!ucbvax!afwl-vax.UUCP!spear
From: spear@afwl-vax.UUCP.UUCP
Newsgroups: mod.computers.vax
Subject: Re: RAM Disks
Message-ID: <8702171732.AA06552@ucbvax.Berkeley.EDU>
Date: Fri, 13-Feb-87 00:30:00 EST
Article-I.D.: ucbvax.8702171732.AA06552
Posted: Fri Feb 13 00:30:00 1987
Date-Received: Wed, 18-Feb-87 06:04:23 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: "SPEAR, JON" <spear@afwl-vax>
Organization: The ARPA Internet
Lines: 24
Approved: info-vax@sri-kl.arpa

At the last DECUS (S.F.) there was a DEC person from the Large Systems Group
or somesuch that was looking for user inputs on high-end storage devices
to include semiconductor "disks". I asked him about the much-talked-about
RAM-disk driver in STABACKIT.COM and he gave a surprising answer.

This type of RAM disk can actually hurt system performance.

The CPU cycles required to read a block from the RAM disk are much higher than
reading from a DMA disk controller, and it still goes through the usual
buffering and RAM cache that a real disk block goes through. The result is that
fewer CPU cycles are available to users when the RAM disk is in use when
compared to the same I/O load from a real disk. 

So, if you have a busy system (there is always a computable process ready to
jump in when another is waiting for a disk I/O), you will probably do better
overall by sticking with normal VMS disk caching than by giving up memory to a
RAM disk. 

Capt Jon L. Spear
AFWL/NTC, KAFB, NM 87117-6008

Disclaimer: This information is provided for comparison purposes only. Your
actual mileage may be different.
------