MDDRIVER John Osudar Electronics Department Argonne National Laboratory 205 A-051 9700 South Cass Avenue Argonne, IL 60439-4837 Phone numbers: FTS: 972-7505 (312) 972-7505 Electronic mail addresses: Bitnet: B35049 at ANLCMT MFENET: B35049@AN2 This directory contains a memory disk driver for VMS V4. A memory disk driver uses a contiguous chunk of memory (e.g. nonpaged pool) to emulate a disk device. Such a disk is obviously "faster" than a real disk that has platters, heads, etc., since there is no seek time, and transfer rates are related to speed of memory-to-memory transfers. The benefits of using a memory disk driver on a memory-rich, CPU-poor system can be seen if commonly used files are located on the memory disk. Many sites have been using PDDRIVER in this way. PDDRIVER is a DEC-supplied driver that is intended for use in building bootable standalone systems onto TK50 tapes. However, the PDDRIVER wasn't necessarily intended for use as a general memory disk driver. It has several shortcomings: first of all, it performs all data transfers at interrupt priority 8, thus locking out a lot of other processing for the duration of the transfer; and, it does data transfers one byte at a time, in a "copy a byte, see if end of page, branch if not" loop. Thus, although the amount of elapsed time required to transfer data between a PDDRIVER memory disk and a user buffer may be smaller than the time for a real disk, it may have a negative impact on the response experienced by all other users -- and it will use up considerably more CPU time to do the transfer than would be required to service a real disk under similar circumstances. The MDDRIVER supplied here resolves those problems by performing transfers either a page at a time or as one large MOVC3 instruction, and by doing transfers at interrupt priority 2 if possible. (When a process is at IPL 2, it may be preempted by a higher software-priority process; this is not true when operating at IPL 8.) As a result, not only are all MDDRIVER data transfers speeded up, but also the impact upon higher-priority processes of MDDRIVER usage by low-priority processes is reduced considerably. Furthermore, the total amount of CPU time used by MDDRIVER for a data transfer appears to be smaller than the CPU time required by a real disk driver to perform a comparable transfer -- which should mean that using MDDRIVER frees up some CPU cycles that would be used if a real disk were involved. MDDRIVER is easy to use -- just copy the MDDRIVER.EXE image to SYS$SYSTEM:, and create a memory disk device using SYSGEN: $ RUN SYS$SYSTEM:SYSGEN SYSGEN> CONNECT MDA0/NOADAPTER/DRIVER=MDDRIVER Then, allocate the amount of space required for your memory disk using the MDA0SET program that is supplied. This program asks for the memory disk size in blocks (pages). Once you have done this, the memory disk appears as another disk on your system. You can do almost anything to it that you can do to a real disk, i.e. INITIALIZE, MOUNT/FOREIGN, etc. Notes of Caution ---------------- Use of MDDRIVER will require modification to some of your SYSGEN parameters. These changes should be made in MODPARAMS.DAT, and an AUTOGEN should be performed to propagate such adjustments to the system. A reboot will be required after modifying these parameters. The parameters that must be set are: NPAGEDYN -- since MDDRIVER uses nonpaged pool as the "disk", you must have enough nonpaged pool to hold the disk's blocks, in addition to the amount your normal system operation requires. Specifying ADD_NPAGEDYN=blocks*512 in MODPARAMS can do this. REALTIME_SPTS -- MDDRIVER uses the "realtime" system page table entries to double-map the user buffer, enabling fast data transfers. MDDRIVER's use of these SPT's is compatible with the code in CONINTERR (the connect-to-interrupt driver), so that if you are using CONINTERR (or other code compatible with it), MDDRIVER will function without disrupting your existing code. This parameter specifies how many SPT's are to be set aside for this purpose. If you are not currently using this feature, this parameter ought zero; if you are using it, it must be nonzero. You will need to increase this parameter by a number that reflects the maximum number of pages of user buffers that can be double-mapped at the same time. Since each SPT costs only four bytes of system space, you can afford to provide as many as 512 or 1024 additional SPT's for MDDRIVER to use. Another note of caution: in its present incarnation, MDDRIVER and MDA0SET do not check whether the memory disk is already in use or not when you run MDA0SET to set the disk's size. If the disk already has blocks allocated, MDA0SET will deallocate them. This can be disastrous if the disk is mounted and in use. I am looking into correcting this situation "in a future release" of the driver.