Eliminating Wasted CPU Time During Multiplexor Emulation
by Irv Bromberg -- Medic/OS Consultants
Revised 29-Dec-85 version 1.4(6)
As described in AMUS.LOG Nov/85 the Medic/OS Multiplexor Emulator can,
in heavy use, lead to excessive consumption of CPU time. The cause of this
problem has now been identified -- it is not due to a defect of the
Medic/OS driver but is caused by the way AMOS/L handles waiting for echo
and waiting for output-in-progress, and the TINPCH and EXIPCH commands
are new programs to correct the problem.
Whenever an input character is received AMOS/L puts the character into
the type-ahead input buffer for the appropriate terminal. It cannot be
removed from this buffer until the character has echoed (does not apply if
echo suppression is in effect). Virtually all software that removes
characters from the input buffer does so via the TIN monitor call (directly
or indirectly). It is the TIN monitor routine which checks for echo
completion and does not allow characters to be removed until they have all
been echoed -- the following is the TIN echo-wait routine translated into
comments:
EchoLoop: Has at least one character been echoed?
If not then goto EchoLoop
If so then get the next input character (TTYIN) and continue...
As you can see from the above the echo-wait loop in the TIN monitor routine
is an extremely tight loop. This loop executes approximately a million
times per second until at least one character has echoed, thus wasting
large chunks of CPU time. Delays in terminal input echo will aggravate
this problem.
Now consider the MUX emulator. If at a given moment it happens to be
at the start of sending an output buffer full to the screen of a CRT
connected to the MUX and at the same moment an operator at another CRT on
the same MUX types an input character, the echo to the second CRT cannot
complete until the first CRT has finished its output buffer. The longer
the output buffer of the first CRT and the slower the baud rate of the MUX
host port, the longer it will take before the second CRT gets a chance to
complete the echo, and the more CPU time will be wasted. Since during
these few or more seconds the CPU is doing nothing else except looping
around the TIN EchoWait loop (don't worry the CPU still services interrupts
efficiently while TIN waits for the echo to complete) other active jobs on
the system will notice delayed response. If the EchoWait loop is being
executed by multiple jobs at the same time (that is if several jobs are
attached to multiplexed terminals) then drastic slowing of CPU processing
may be observed.
Alpha Micro could easily modify the TIN monitor routine for future
releases of AMOS/L to correct this problem by inserting a SLEEP instruction
to be executed each time around the loop, and we will be suggesting this
change to them. In the meantime Medic/OS has developed TINPCH.LIT, a new
command intended to be invoked in the bootup .INI file (AMOS/L versions 1.2
and later), which patches the echo-wait loop of the TIN monitor routine so
that is uses a 50ms SLEEP each time around the loop. This dramatically
improves system performance in intensive applications of the Medic/OS
multiplexor emulator (see AMUS.LOG Nov/85). There is also some benefit in
installing this patch in any AMOS/L system even if it is not using MUX
emulation, since some CPU time is wasted in all systems waiting for
characters to echo (especially likely to be of benefit on systems having
many terminals at low baud rates).
The operating system does not wait for echo if the terminal has echo
suppressed, so CPU time wasting does not occur. Under AMOS/L there are
several ways to suppress echo:
-- SET NOECHO command at monitor-level
-- Set bit #7 of TDV attributes word in the terminal's TDV (used for
half-duplex terminal drivers)
-- XCALL NOECHO from AlphaBASIC (also sets IMI mode)
-- Set ECS or LCL bit of T.STS(TCB) from assembly language
An analagous CPU time-wasting loop occurs in the EXIT monitor call.
EXIT must restore the Terminal Status Word that existed prior to the
command that has just EXITed but before doing so must wait for any
output-in-progress to finish:
MOV JOBTRM(JCB),TCB ; point to user's Terminal Control Block
WaitOIP: TSTB T.STS(TCB) ; is the OIP bit set?
BMI WaitOIP ; result negative if OIP not finished yet
; (next the previous Terminal Status Word gets restored)
Again we have here a very tight CPU time wasting loop that will cause
degradation of system performance wherever low baud rate terminals are
being used or where intensive multiplexor emulation is being used because
in both of these situations it takes longer for output-in-progress to
finish.
The EXIPCH command patches the EXIT monitor call in a manner analogous
to the way that TINPCH does, causing a 50ms SLEEP instruction to be
executed each time around the WaitOIP loop.
Thus TINPCH used together with EXIPCH make your system more efficient,
even if multiplexor emulation is not being used.
See the source code in TINPCH.M68 and EXIPCH.M68 for further
information and installation instructions.
At the time of writing TINPCH and EXIPCH have been tried under AMOS/L
1.2A(106) and 1.3(123). If you have a different version of AMOS/L try it
anyways -- if these programs says they have installed the patch and the
rest of bootup proceeds normally then the patch is successful on your
system, please let me know about it for my reference.
See also the source for the commands FLUSH, XFORCE, and WAITMX which
are intended to replace KILL, FORCE, and WAIT in your bootup .INI file.
These also prevent CPU time wasting by clearing the echo character count if
flow inhibition is preventing echo from completing. In addition they allow
your system to boot up properly when using the RS-232 DTR line for output
flow control (many types of terminals and printers pull down the DTR line
when they are powered off, thus interfering with normal system bootup).
