1
Download VAX MP Technical Overview
Transcript
Thus underlying host IO methods utilized by various VAX MP IO devices can be summarized, for initial intended VAX MP public release, as follows: Device kind MSCP disks SIMH name RQ MSCP tapes TQ Ethernet XQ Host IO method and use status Asynchronous (IOP), preferred kind of disk device to use Asynchronous (IOP), preferred kind of tape device to use Either asynchronous (IOP) or synchronous non-blocking polling Synchronous non-blocking polling terminal VH, DZ multiplexers, TTI, TTO console port floppy disk RY Synchronous blocking, but to memory buffer, so actually no blocking for extended time tape TS Synchronous, blocking, intense use is discouraged (at least until the handler is modified to use IOP) disk RL Synchronous, blocking, intense use is discouraged, certainly not as system disk printer LPT Synchronous, blocking, intense use is discouraged punch card CR Synchronous, blocking, reader intense use is discouraged Now let’s turn to particular devices and timeout utilization by their VMS drivers. For most system configurations and usage patterns, MSCP disks are typically by far the most important kind of device in terms of the number and rate of IO operations performed. Luckily, their affinity does not have to be constrained to the primary processor, and they can be accessed for IO initiation by any virtual processor and use IOP threads without concern for risks of device timeout. 101 VMS MSCP/TMSCP port driver (PUDRIVER) uses a variety of timeouts during initialization, but they cannot cause the early timeout problem we are discussing here, because MSCP controller initialization on VAX MP is performed before multiprocessing is started and do not involve actual disk IO, and thus do not involve IOP threads: all controller initialization is performed within the context of primary CPU. VMS PUDRIVER also utilizes CRB timeout mechanism to establish periodic 15-second polling that checks for uncorrectable errors signaled in the controller’s CSR, however there is no harm if some of these polls cycles will get triggered earlier (relative to device activity) than intended. VMS DUDRIVER uses timeout defined by the value of MSCP controller timeout reported by the controller at initialization. SIMH module PDP11_RQ.C(CPP) defines it via preprocessor symbol RQ_DCTMO with value of 120 seconds in the original uniprocessor SIMH version. This value is generally sufficient to safeguard against false early timeout due to VCPU 101 Note that here and below we are discussing QBus and Unibus controllers, not BI controller or HSC. 86
