.; Please use Bonner Lab Runoff on this document .; .PAGE SIZE 58,70,10 .AUTOPARAGRAPH .TAB STOPS +8,+8,+8,+8,+8,+8,+8,+8,+8 .TITLE QT: Tape Caching Driver .HEADER LEVEL 1 What QT: Does The QT: driver acts as a cache buffer between a task and a physical tape drive. It can result in significant performance gains if a streaming drive is used with a program that is too slow to keep it streaming (e.g. BRU's verify pass on a TK50). The QT: driver has been tested on RSX-11M-PLUS version 3.0 and 4.0 systems, with various tape drives using the MS: and MU: drivers. Streaming tape drives normally exhibit poor start-stop performance because there is nothing in the tape path to absorb the shock of stopping and starting the tape. The tape overshoots the inter-record gap on stopping, so it has to run the tape backwards before it can reverse direction again to read or write the next record. This often results in performance penalties in excess of a factor of 5. The QT: driver is conceptually similar to the virtual disk drivers written by Ralph Stammerjohn (and others). It accepts I/O packets from tasks via the QIO mechanism and passes them to the physical device driver. In addition, the QT: driver reads ahead (and can write behind if you tell it to) in an attempt to optimize the tape motion. This activity requires the creation of a memory region in which to buffer the data, and the allocation of an internal I/O packet and a number of (6-word) buffer descriptors from pool. The internal I/O completion mechanism used for disk data caching is also used by the QT: driver. The QT: driver begins reading ahead when an IO.RLB request is received by the driver; reading ahead will stop when all buffers have been filled, or when any kind of error condition has been detected (e.g. EOF). This allows the QT: driver to overlap tape reads with task processing, as well as reading the tape in large enough chunks to prevent excessive direction reversals. Data is transferred between the buffers and the task via $BLXIO. When writing behind is enabled, the driver copies data to be written to buffers and immediately passes success to the requesting task. The buffers are written as fast as the hardware and internal I/O completion mechanisms will allow. If any errors are detected while writing behind, then the write-behind queue is flushed, and a fatal hardware error status (IE.FHE) will be returned by the QT: driver for all functions until the tape is rewound. This is done primarily so that the tape will not be pulled off of the supply reel due to the delay in returning end of tape status. Unfortunately, QT: is not smart enough to allow multi-reel tape sets to be made when writing behind is enabled. .HEADER LEVEL 1 Building QT: A command file is supplied, QTGEN.CMD, to assemble and task build QTDRV and QTA (QT: unit assignment program). This command file asks how many units you want, where to find a copy of RSXMC.MAC on LB:, and whether or not you want listings. At this time, the QT: driver is not vectored, so QTGEN must be able to locate RSXMC.MAC and RSX11M.STB. If no errors are generated, then you should transfer QTDRV.TSK and QTDRV.STB to your SYSUIC, and you should transfer QTA.TSK to your LIBUIC and install it. .HEADER LEVEL 1 Using QT: Load the QT: driver into memory with the following command: .LITERAL MCR>LOAD QT:/PAR=GEN/HIGH .END LITERAL Assign a QT: unit to a physical tape device with a command like this one: .LITERAL MCR>QTA QT0:=MS0:/NU:20 .END LITERAL The legal switches are /BS:size (used to specify maximum tape block size), /NU:number (used to specify the number of buffers to allocate), /PA:partition (specifies the main partition in which to create the buffering region), and /WB (enables write-behind caching). By default, 15 buffers of 4160 bytes each are allocated in GEN, and write-behind caching is disabled (defaults are set in QTPRE.MAC). Since the maximum record size used by BRU is 4144 bytes the default buffer size is just fine. Some drives may work better with more than 15 buffers, but the TK25, TK50, and TU80 all stream pretty well on the verify pass of BRU. Feel free to increase the number of buffers if you have the memory. A region called QTnBUF is created to hold the buffers. Bring the unit online: .LITERAL MCR>CON ONLINE QT0: .END LITERAL The physical tape unit status will be changed to reflect the fact that user tasks cannot use it directly. Since the MU: driver checks that the device is mounted, the physical device is made to look like it is mounted foreign. Mount the unit foreign: .LITERAL MCR>MOU QT0:/FOR .END LITERAL Labeled tape processing requires that US.LAB must be set in the U.STS byte in the physical device's UCB. The present implementation of QT: does not do this, so it is recommended that only utilities that require the tape to be mounted foreign be used with QT: To stop using the QT: driver, dismount the unit, and bring it offline with a command like this: .LITERAL MCR>CON OFFLINE QT0: .END LITERAL The QT: unit will be detached from the physical device and the buffering region (QTnBUF). The buffering region should be removed with a command like this: .LITERAL MCR>REM QT0BUF/REG .END LITERAL QT: was designed to be used with BRU, although it can be used with other programs. It seems to work pretty well, but no guarantees are made. There may be conditions of which I am not aware that may result in the destruction of valuable data, media, hardware, and/or personnel. I refuse to be held responsible for any problems short of the destruction of the universe as we know it (and just try to catch me then). Some programs and command files check the device name supplied to be "sure" that it is a valid tape device. To fool BASTART.CMD (used to load the second backup set from a distribution tape prior to a SYSGEN) just assign QT: to a legal tape device name (e.g. ASN QT:=MM:). Programs such as FLX, however, check the redirected device name; this means you have to do one of the following: rename the driver at the source level, find the QT: DCB in pool after loading QT: and change the device mnemonic, or forget about using the QT: driver with FLX (it doesn't seem to help much anyway). Happily, BRU does not try to play these kinds of games.