From: Charles Hornig To: MTB Distribution Date: January 26, 1983 Subject: Problems with MCS (MTB-607) ABSTRACT This MTB discusses the state of the Multics Communications System (MCS) as it is expected to stand at the end of the MR10 time frame. There are many problems with this critical Multics subsystem. The time has come to take a fresh look at Multics' communications needs and step out into the 1980's. This is the first of a series of MTB's considering the future of MCS. Future MTB's will discuss requirements for MCS in the 1980's and propose a plan for meeting these requirements. COMMENTS The Forum meeting "New_MCS" (short name "new_mcs") has been created on System-M in >udd>Multics>Hornig>meetings to facilitate discussion of this topic. If possible, please use this forum to make any comments on this MTB. If you do not have access to System-M, please send mail to "Hornig -at MIT-Multics" or via U. S. Mail to: Charles Hornig Cambridge Information Systems Laboratory 575 Technology Square Cambridge, Massachusetts 02139-1986 _________________________________________________________________ Multics Project internal working documentation. Not to be reproduced or distributed outside the Multics project. MTB-607 PROBLEMS WITH MCS 01/26/83 THE CURRENT IMPLEMENTATION MCS, as currently implemented, may be divided into several distinct parts. These are the code running in the Front-end Network Processor (FNP), the "ring-zero multiplexers", the "ring-zero TTY DIM", the user-ring I/O modules, administration and control, and debugging support. These will be described below. For more detailed descriptions, consult the MULTICS COMMUNICATIONS SYSTEM SYSTEM DESIGNER'S NOTEBOOK (AN85), MULTICS MENU CREATION FACILITIES (CP51), the MULTICS PROGRAMMER'S MANUAL -- COMMUNICATIONS (CC92), and the MULTICS ADMINISTRATOR'S MANUAL -- COMMUNICATIONS (CC75). Front-end Network Processor (FNP) The FNP is a dedicated minicomputer which controls communications lines for a Multics system. It is connected to the central system through a Direct Interface (DI) channel to the IOM. Multics supports two models of the FNP. The Datanet 355 (now known as the Datanet 6632) provided the original communications support when Multics moved to the 6180 processor. The Datanet 6661 (and its predecessor, the Datanet 6678) are a reimplementation of the 355 architecture using the technology of the Level-6 minicomputer. The 355 and the 6661 differ primarily in their extended memory implementation and in the elimination of the Low-Speed Line Adaptor (LSLA) on the 6661. There are also two versions of the FNP code. One is a frozen older version than runs on both the 355 and the 6661 using 32K of memory. The current version runs only on the 6661 with 64K-256K of memory. While there are many differences between the two versions, their broad structure is the same. The FNP code consists of a scheduler; utilities for managing buffers and other useful things; device drivers for the Direct Interface Adaptor (DIA), Line Adaptors (HSLA and LSLA), and the FNP console; an interpreter for the "control tables"; the "control tables" themselves; debugging support (breakpoints and tracing); and initialization code. All FNP code is written entirely in 355MAP, the 355 Macro Assembler. In most cases, the communications protocols are implemented as "control tables" which are interpreted, rather than actual machine code. The following protocols are supported: * Asynchronous ASCII * IBM 1050 * IBM 2741 * ARDS * Honeywell G115 * BISYNC * Terminet 1200/202 modem MTB-607 PROBLEMS WITH MCS 01/26/83 * Honeywell VIP * X.25 level 2 * IBM 3270 * HASP Support is also provided for Automatic Calling Units (ACU's) and the COLTS on-line T&D's. In total, the FNP code contains about 40000 lines of 355MAP code. Ring-zero Multiplexers The ring-zero multiplexers provide a framework within the Multics supervisor for implementing multiplexed communications protocols. They were created when the need for support for such protocols became clear. Adding support for multiplexed protocols to the FNP was considered impossible without a complete redesign. Within this framework, support currently exists for the IBM 3270 (BSC version), VIP 77XX, X.25 level 3, and HASP protocols. The framework is also used to support communication with the FNP itself and for the software terminal facility. This code largely runs in a ring-zero masked and wired environment. It consists of about 25000 lines of PL/1 and a small amount of ALM. Ring-zero TTY DIM The ring-zero TTY DIM provides an interface between outer-ring processes and the multiplexer hierarchy. It also provides, on request, most of the standard Multics terminal functionality. Canonicalization, erase and kill processing, escape processing, translation and conversion on both input and output, and echo negotiation are all done here. Originally written to perform in a simple line-at-a-time environment, it has been enhanced piecemeal to support more sophisticated terminal functions, such as the window/video system and emacs. It consists of about 7000 lines of PL/1 and a small amount of ALM. User-ring I/O Modules The MCS I/O modules which run in the user ring are bisync_, g115_, hasp_host_, hasp_workstation_, ibm3270_, and tty_. All of these modules make use of the interface provided by the ring-zero DIM. In addition, the Answering Service module astty_, the Message Coordinator, the Transaction Processing module tp_tty_, the console_server, the window/video system, and the emacs editor use this interface. All together, thse amount to about 30000 lines of PL/1 code. Administration and Control Administrative control of MCS is largely done by the Answering Service through the module multiplexer_mgr_. This program uses a MTB-607 PROBLEMS WITH MCS 01/26/83 large installable table, the Channel Definition Table (CDT), to control its operation. Tools also exist to compile, update, and display this table. Another installable table, the Terminal Type Table (TTT), contains information used by the user-ring I/O modules and by the ring-zero TTY DIM to control their behavior for different terminals. Similar tools exist to maintain this database. A large body of metering tools also exist. Both the FNP and all ring-zero code meter their operation extensively. The system_comm_meters and channel_comm_meters programs report this information in human-readable form. The adminitrative and metering code amount to about 15000 lines of PL/1. Debugging Tools also exist to facilitate debugging of communications problems. These include interactive debug of the FNP with debug_fnp, tracing of events in ring zero with trace_mcs, display of ring zero databases with tty_dump, and crash analysis with tty_analyze. About 15000 lines of PL/1 are devoted to debugging. CURRENT PROBLEMS Many problems exist with the current implementation. Most of these can be traced to attempts to adapt the software to perform functions which were not anticipated at the time it was designed. This is especially apparent in the FNP, which is the oldest area of the system and the most difficult in which to make major changes. It also applies to some extent to the ring-zero parts of the system. The user-ring code has been largely immune to this problem, since it can be more easily replaced. This, in fact, has happened. The tty_ module, emacs, and the window/video system each use completely different implementation to perform essentially parallel functions. The existing problems and limitations will be discussed in more detail below. FNP Problems As described above, the problems with the FNP are especially severe. These begin with the Datanet 6661 hardware. The machine architecture, with its two accumulators and three index registers, is remarkably weak by today's standards. This makes it extremely difficult to program, in comparison with modern minicomputers. No programming languages other than 355MAP are available for it. While it can support 256K 18-bit words of physical memory, its virtual address space is limited to 32K words. Use of extended memory requires continuous tinkering with the pager, again increasing the complexity of programs. Its I/O architecture also limits it to three simulated HSLA's, for a maximum of 96 supported lines. It also will not support the new MTB-607 PROBLEMS WITH MCS 01/26/83 communications hardware being developed for the DPS-6, such as the high-speed Single-Line Communications Channel (SLCC) and the New Multi-Line Controller (NMLC). These problems are carried over in the software. While the basic structure of the FNP software was well-suited to the needs of the time it was written, it has not adapted well to those of today. The addition of breakall and oflow modes, echo negotiation, and buffer preallocation have significantly increased the complexity of the system because of their need to circumvent existing mechanisms. This has resulted in large parts of the FNP software being essentially unmaintainable. Fixing even minor problems in areas, such as the HSLA status processor, which have been extensively modified requires a very large investment in time and energy by the developers. Readers of TR phx09129 will note the many problems with output flow control as an example of this. We are also running into the performance limits of the 6661 processor. Work with X.25 has already run into problems with bursts of input completely saturating a FNP. While buffer preallocation has alleviated the problem of burst loads, the trend towards more sophisticated terminal interaction will continue to increase FNP loads until the 6661 can no longer support them. Multiplexer Problems The multiplexers have their problems too. The multiplexer hierarchy was conceived as a means to permit support for a variety of hardcore multiplexors within a common framework. Within those bounds it has succeeded. However, the architecture is not well adapted to supporting more modern communications network protocols. Its static database allocation requires that all attributes of each subchannel be declared at the time the multiplexer is configured. While this is appropriate for a VIP controller or even a FNP, it is totally inappropriate for packet-switched or local-area networks. In these networks, connections are created and destroyed dynamically, not preconfigured. Current attempts to support X.25 properly are running into serious difficulties with this problem. TTY DIM Problems The problems here are due to the need to add new terminal management functions to a program poorly arranged to handle them. The new functions added have been primarily for support for emacs and the window/video system, and include echo negotiation, marks, and the 'write whole string' capability. The TTY DIM also provides only a stream interface to user-ring programs. This makes dealing with record-oriented devices difficult. Also, many terminal management functions are driven from the TTT. This MTB-607 PROBLEMS WITH MCS 01/26/83 table-driven approach has proved unable to deal with the capabilities of modern terminals. User-ring Problems Since user-ring programs can be replaced by the user, we do not see the lack of functionality or excessive complexity described above. Instead, we see many parallel attempts to provide the same function. Each of the Answering Service, the emacs editor, and the window/video system has its own replacement for the tty_ I/O module. This duplication creates its own maintainability problems. Administration and Control As has been noted above, the static CDT and TTT structures are not well suited to the more complex needs of modern communications processing. Better support of distributed networks will require drastic changes in the way that communication functions are administered. It must be possible to reconfigure all aspects of a communications channel without affecting the operation of other channels. Debugging and Metering This is our one strong point. The extensive debugging and metering support in MCS cannot be faulted. NEW FUNCTIONALITY At the present time there is a great deal of demand for new communications functionality. This demand is coming largely from two sources, the window/video system development effort and the expansion of Multics networking capabilities. The window/video system needs real-time input editing without central system overhead. Network implementors need extremely high throughput, better response time, and also less overhead. These needs cannot be met within the current system. They can and should be met by any replacement for it. Another requirement which must be met is that the replacement allow much more architectural flexibility then the current MCS. We need to support a wide variety of Honeywell and foreign equipment through many different communication media. In addition, the concept of 'distributed' front-end processors should be supported. This would permit processing performed by the FNP to be done by a FNP at a remote site. This FNP would communicate with the local Multics FNP over any of a number of communications media. This allows us to distribute communications processing power where it is needed, and eliminate unnecessary communications overhead.