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.