These buffers are considered a system resource, .and a sufficient
num-ber must be configured at system generation time. If an insufficient
number is configured, jobs running on the system can become stalled
waiting until enough buffers are freed by jobs currently claiming
their use.
RSTS/E System Generation
Small buffers are 16-word blocks residing in the Monitor part of memory. The number needed by a system at anyone time depends upon the dynamic requirements of the jobs on the system. For efficient system operation, i t is recommended that at least l~ small buffers be allocated for each possible job. Thus, on a 32-user system, 32~ small buffers should be available. (An indicator of good system performance is that the number of free small buffers, as reported by the SYSTAT system program, never drops below ten. Refer to the description of SYSTAT in Section 7.2 of the RSTS/E System Manager's Guide.
On systems configured for 16 or more jobs, l~ small buffers for each job is usually an adequate number. However, on systems configured for fewer than 16 jobs, i t may be advantageous to include more than l~
small buffers per job. For example, each active terminal requires 4 or 5 small buffers for performing input and output operations. A sys-tem having 8 terminals therefore needs between 32 and 4~ small buffers if all terminals are to be simultaneously active. Each active job re-quires three small buffers. Thus, if the same system required that ten jobs be able to run simultaneously, 3~ more small buffers would be needed. For each job that will run detached from all terminals, sub-tract the four small buffers required for terminal I/O. A running total on the 8-terminal, l~-job system is 62 small buffers for these two simple p~ocessing requirements.
Next, in the sample system, consider what kind of processing is necessary. One small buffer must be added for each open file on the system. If each program running on the system opens two disk files, 2~ more small buffers must be added. If all the active programs open the maximum number of files simultaneously, 12~ small buffers must be available. (BASIC-PLUS allows 12 open channels per user program.) In an average system, the two file situation is muqh more likely, so the sample system requires 2~ more small buffers for a total of 82.
The system requires small buffers for certain transient opera-tions. One small buffer is used for each disk transfer queued by the monitor. Programs such as QUEMAN, QUE, ERRCPY, RJ278~, BATCH, and SPOOL communicate through the SEND/RECEIVE system function call which claims one small buffer for each message queued for a receiving job.
Normally the buffers used for these operations are employed for very
RSTS/E System Generation
Line printers on the system exhaust as many as one third of the available small buffers. A lower number of available small buffers places a larger burden on the system. For example, if 3~ small buf-fers are available for use by the printer driver, the system can have
9~~ characters buffered for output to the line printer. Assume that a line printer is running at 3~~ lines per minute (5 lines per second) and that an average line is 9~ characters. Such a line printer empties the buffers in two seconds. A spooling program for that line printer would have to be swapped into memory every 2 seconds to keep the line printer running at full speed. (For a line printer running at l2~~
lines per minute, a swap operation would be necessary everyone half second.)
The total requirement on the l~ job, 8 terminal system is nearly
l4~ small buffers for an average system load if the transient require-ment for 2~ is added and one third of the subtotal is added to handle the line printer running full speed (3~~ lines per minute). Thus, the guideline of l~ small buffers per job is too low on such a small system.
Moreover, if small buffers were subtracted from l4~ to account for idle terminals and detached jobs and to allow for some slow down in line printer operations, the guideline is still inadequate. On such a sys-tem, between 12 and 14 small buffers per job is a better approximation.
For larger systems having 16 or more jobs, ten small buffers per job is usually a good approximation. Except for occasions of heavy keyboard and line printer activity, enough free small buffers will be available to maintain good system throughput.
2.7.19 Big Buffers
Big buffers are 256-word blocks of monitor memory used for DEC-tape and 278~ operations. Since the SYSGEN program automatically con-figures four big buffers for 278~ software, big buffers need be con-figured only if DECtape is on the system. Consequently, SYSGEN prints the BIG BUFFER question only if DECtape is on the system.
On systems without 278~ software but with DECtape devices, one big buffer is normally provided for each DECtape drive. However, one big buffer per drive is not a definite requirement since one big buffer can accommodate any number of DECtape drives for non-simultaneous
opera-RSTS/E System Generation
On systems with both RSTS/278~ software and DECtape drives, one big buffer is sufficient for eight DECtape units. The four big buffers automatically included for RSTS/278~ software are available for DECtape operations when the RSTS/278~ software is not operating. In any case, the SYSGEN program does not allow less than one big buffer when DECtape is present on the system. This fact applies whether or not the 278~
software is present.
2.7.20 Receivers
A receiver is a job capable of performing interjob communication using the SEND/RECEIVE system function call described in Section 7.2.12 of the RSTS/E Programming Manual. The QUEMAN job and each SPOOL and BATCH job running on the system performs as a receiver. Enough receiv-ers must be configured for such jobs and for additional programs which declare themselves receivers. For example, on a system running one SPOOL program and one BATCH program, configure at least three receivers
(QUEMAN, SPOOL, and BATCH) . 2.7.21 Power Fail Recovery Code
RSTS/E systems can attempt to recover from a momentary power fail-ure by performing an automatic restart procedfail-ure. A momentary power failure is defined in Section 5.3 of the PDP-ll/7~ Processor Handbook and in Section 2.7.1 of both the PDP-ll/4~ Processor Handbook and PDP-ll/45 Processor Handbook.
2.7.22 File Processor (FIP) Buffering and Disk Caching
The optional FIP buffering module accelerates file processing on the RSTS/E system. The module reduces the number of accesses to the disk by maintaining more than one disk directory block in memory.
Normally, RSTS/E employs only one permanently allocated 256-word buffer to store disk directory information. File processing is often delayed because, at any given time, the directory block which the file processor needs is not the one currently in its buffer.
The FIP buffering module claims, from the normal buffer pool, free
RSTS/E System Generation
uses, the system releases them from the FIP buffering module. The num-ber of buffers configured for other system operations need not be in-creased when FIP buffering is included on the system.
The system manager can enhance FIP buffering on RSTS/E by allocat-ing memory solely for the module. FIP buffering is like cache memory operation wherein faster access semi-conductor memory holds frequently used code or data to avoid accesses to slower core memory. FIP buffer-ing is a disk cachbuffer-ing mechanism which maintains frequently used disk directory blocks in memory to avoid accesses to the slower access disk.
The CACHE command in the TABLE OPTION portion of the DEFAULT and START options can reserve a fixed amount of memory for FIP buffering.
Memory reserved for disk caching is exhausted by the FIP buffer-ing module before small buffers are employed. The reserved memory thus prevents degradation of performance on a heavily loaded system when small buffers are most likely to be claimed by user jobs and are most needed for FIP buffering. (See Section 3.6.3.7 for more information on disk caching and the CACHE command.)
The FIP buffering module increases the size of the monitor and is therefore an option on all RSTS/E systems. (See Appendix D for infor-mation on the size of optional modules.)
2.7.23 Resident Code
Certain portions of the overlay code can be configured resident in memory during time sharing rather than stored on the disk. Per-formance is thereby improved on systems where that code has heavy usage.
The most important code in terms of system performance is the disk handling code. This block of code includes: the system routines for disk file creation; OPEN, CLOSE, and RENAME routines; some routines needed to process the RUN command; general routines for opening other devices, deassigning devices, fetching error messages, looking up files by name; and for logout. It is recommended that systems with more than 56K words of memory have disk handling code resident.