Trailing-Edge
-
PDP-10 Archives
-
bb-bt99e-bb
-
anfv23.d09
There is 1 other file named anfv23.d09 in the archive. Click here to see a list.
EDIT DESCRIPTIONS FOR ANF10-V23
EDIT 11034 FOR ANF
[Symptom]
DGUTS CONDITIONAL IN ANF CODE BACKWARDS
[Diagnosis]
.IF NE SHOULD BE .IF EQ
[Cure]
SWITCH IT
********************************************************************************
EDIT 702038 FOR ANF
[SYMPTOM]
TTY characters lost on "high speed input", in particular with regard
to ANF-10/DN8x terminals.
[DIAGNOSIS]
The problem is several-fold. The "fixes" described below do not
constitute a rigid solution to the problem, they merely describe a set
of "adjustments" to ameliorate the problems. We believe that any
further improvement would require a change in the NCL protocol, and we
will keep this under consideration for possible future releases.
The following discussion is based on the 7.02 version of both the -10
and -11 code (although the -10 code (SCNSER) has not changed
substantially, the -11 terminal service has undergone significant work
since the 7.01A release).
I.
First and foremost is the "flow-control protocol" between the host
(TOPS-10) and the remote (typically a DN8x, but can also be another
host). Basically, when the -10 decides that the TTY input stream is
"full" a logical XOFF is transmitted to the terminal. For "hardwired
lines" such as the DZs on the KS-10 a real XOFF character is sent to
the terminals. For network terminals such as on the DN8x a "buffer
low" control message is sent to the remote - where it is the remote's
responsibility to cause the flow of data into the -10 to cease (and in
fact the DN8x sends an XOFF to the terminal on behalf of the -10,
bypassing the normal output character stream buffered up within the
-11).
Independently of the host's buffering and processing of characters,
the remote is also flow-controlling the terminal line, buffering
characters to be sent to the host. When the remote's local TTY input
stream is "full" it will XOFF the terminal independently of (and
essentially invisibly to) the host.
It is this parallel and simultaneous flow-control which leads to
confusion between the remote and the host. In particular, if the host
sends an XOFF just as the remote is deciding that it should also XOFF
the terminal, the remote will then shortly XON the terminal (as soon
as it can flush its pending buffered characters to the host and has
buffer space), so getting more terminal characters which are in turn
dutifully sent to the host, which will then run out of buffer space
and discard the "excess" characters.
The accompanying DNTTY patch addresses this problem by attempting to
"override" the remote (DN8x only, no provision is made herein for
mainframe hosts acting as remotes) flow control with the host flow
control (the "BIC #DS.IST,@J" instruction clears the fact that the
DN8x has sent an XOFF already, and relies on the terminal to honor the
XOFF generated, and so not push the DN8x into exerting its own flow
control.
This patch still leaves a narrow window, however, where the DN8x will
immediately re-assert DS.IST - if a character is in the process of
being received (by the hardware) as the XOFF is generated on behalf of
the host (and the DS.IST flag is cleared), and if that character
overflows the DN8x buffer "warning" level, then the DN8x will start
exerting its own flow control again, defeating the host's attempt to
override the DN8x. As soon as the DN8x can ship its buffered data to
the host, it will XON the terminal (clearing DS.IST), thus restarting
terminal input, and thus exceed the host buffering, resulting in lost
data, albeit somewhat less often.
To address this problem, the SNDXOF routine in the TOPS-10 monitor
(see the SCNSER FILCOM) is also modified. This results in the host's
periodically attempting to "retry" an XOFF if previous attempts to
XOFF the terminal have elicited no success. The exact definition of
"periodically" is left dependent on the buffering values of the host
and the remote (see "tuning" further down), and is chosen so that an
XOFF retry should only be attempted roughly once per possible
"spurious" XON in the remote. This also works equally well for
non-network terminals (which could conceivably have lost the XOFF for
their own reasons).
II.
A secondary problem now arises in the host ("SCNSER") code in the
calculation of warning and discard thresholds. For PIM mode input the
thresholds are calculated dynamically. Actually only the warning
threshold is dynamic, the discard limit is a fixed function of the
warning level, and it is this fixed-function discard limit that can
cause "unwarranted" loss of data.
First, the fixed offset is too small. Since a incoming DN8x terminal
data message can hold up to TTYMIC characters (see "tuning" further
down), where TTYMIC is by field-image default (^D60) greater than the
warning-to-discard offset (^D20), it is possible for a single input
data message to store some characters, exceed the warning level, queue
up a "buffer low" control message (see above), continue storing more
characters, and finally exceed the discard limit, thus discarding the
remainder of the data message.
However, even making the fixed-offset much larger still leaves open
another more insidious problem - it is possible for a previous data
message to have completely "fit" without exceeding the warning level,
then the warning level gets dynamically recalculated (because of a
sudden flurry of activity on a lot of terminals for example), dropping
by a sufficiently large amount that the new discard limit is less than
the previous warning level - ANY data now arriving will be discarded
with no warning whatsoever having been given to the terminal/sender.
For this reason, the warning and discard thresholds for PIM mode
terminals have been made static (ASCII and IMAGE mode were already
static, and so didn't suffer the dynamic threshold problem).
III.
Finally, some words regarding "tuning" for safe high speed input
operations.
It is important to bear in mind that the above "fixes" merely provide
the framework in which the window for loss of data can be made
arbitrarily small - THE POSSIBILITY STILL EXISTS FOR DATA TO BE LOST.
This section describes the tradeoffs involved in tuning for high speed
input.
First off, the parameters involved:
TTYMIC Defined in DNCNFG.P11, settable via DN8x configuration
parameter file at DN8x assembly time.
The size of the DN8x's terminal input "buffer" - how many
characters the DN8x will buffer before discarding excessive
input. The XOFF threshold is "TTYMIC-20".
Defined in SCNSER.MAC.
This parameter is also defined in SCNSER so that SCNSER can
calculate a reasonable XOFF retry interval based on the
"known" operation of the DN8x remotes.
Default value: 60 (decimal).
TTIBRK Defined in SCNSER.MAC.
The number of characters that SCNSER will buffer in ASCII mode
before triggering a "break" condition and causing the user
program to wake up and see a "line" of input available. Does
not affect IMAGE or PIM input.
Default value: 132 (decimal).
TTIWRN Defined in SCNSER.MAC.
The number of characters that SCNSER will buffer in either
ASCII or IMAGE modes before attempting to shut down the input
stream via a "buffer low" or XOFF condition.
Default value: 200 (decimal).
TTIMAX Defined in SCNSER.MAC.
The absolute maximum number of characters that SCNSER will
buffer for a given terminal line in ASCII or IMAGE modes
before discarding characters.
Default value: TTIWRN + 5*TTYMIC.
TTPBRK Defined in SCNSER.MAC.
The number of characters that SCNSER will buffer in PIM mode
before triggering a "break" condition and causing the user
program to wake up and see a buffer of input available. Does
not affect ASCII or IMAGE input.
Default value: 132 (decimal).
TTPWRN Defined in SCNSER.MAC.
The number of characters that SCNSER will buffer in PIM mode
before attempting to flow-control the input stream via a
"buffer low" or XOFF condition.
Default value: 500 (decimal).
TTPMAX Defined in SCNSER.MAC.
The absolute maximum number of characters that SCNSER will
buffer for a given terminal line in PIM mode before discarding
characters.
Default value: TTPWRN + 5*TTYMIC.
TTCHKN Defined in COMDEV.MAC, used in COMMON.MAC, settable via MONGEN
"symbol,value" dialog.
The total number of chunks available for SCNSER to distribute
among all terminals, on a demand basis.
Default value: 6 * <total number of TTYs+PTYs+CTYs in system>
The TTYMIC parameter directly controls the buffering available in the
DN8x, and indirectly controls the ultimate limit on throughput to the
host. The network terminal input protocol is essentially a
half-duplex protocol requiring that each terminal input data message
be ACKed before the remote can send another data message. (The term
"half duplex" used here is solely internal to the operation of the
network, the terminal is still a "full duplex TTY".) The larger the
value of TTYMIC, the larger the individual bursts of data to the host
can be, and the greater the possible throughput.
For a value of 60 (decimal), a DN87S can maintain a 7.5-8.0Kb rate of
data flow to the host for an indefinite period of time (all data rates
assume the terminal running at 9600 baud, PIM mode input (ASCII
typically about 10% less), no other load on the system, and a DN87S
talking to a KL10 via DTE, unless otherwise qualified). For a DN82
using a 19.2Kb link to a DN87S using a DTE to a KL10, the rate drops
to about 4.5-5.0Kb (this is the manifestation of the half-duplex
network terminal protocol). The DN87S is XOFFing the terminal line
about 10-15% of the time, while the DN82 is XOFFing the line almost
50% of the time.
Increasing TTYMIC to 120 (decimal) raises the DN87S data rate to about
9.0Kb, and the DN82 data rate to about 6.0Kb. The DN87S is
effectively never XOFFing the terminal (the test system generating the
data flow was itself only running at about 9.0Kb output of data),
while the dn82 was still XOFFing the terminal for a significant amount
of time.
Further raising TTYMIC to 180 (decimal) has no significant impact on
the DN87S, but raises the DN82 data rate to about 9.0Kb. At this
point neither the DN87S nor the DN82 is XOFFing the terminal.
The significance of the DN8x XOFFing the terminal is simply the
probability of exercising the window mentioned in "I" above - namely
the destructive interaction of the host and remote both trying to flow
control the same terminal at the same time. The less likely it is
that the DN8x must XOFF the terminal, the less likely it is for the
host flow control to be defeated by the DN8x flow control. The
tradeoff in increasing the size of TTYMIC is how much DN8x memory
("chunk") space will be dedicated to holding terminal characters,
although the difference between 60 and 180 is only two chunks
(assuming default 64 byte chunk size).
The TTIWRN/TTPWRN and TTIMAX/TTPMAX parameters carry a little more
significance, they control how much data the host must buffer on a
long-term interval (until the program gets around to reading the data,
on a loaded system this might be many seconds). (The remotes never
"store" data, they always ship it to the host as soon as possible.)
For any TTIWRN/TTPWRN value significantly over TTYMIC (say 2*TTYMIC)
an unloaded host can trivially keep up with the remote. The default
values selected for the TTIWRN/TTPWRN values seem reasonable for most
systems, the ASCII value assuming user typein (even a heavily loaded
system can keep up with most humans' ability to type), while the
larger PIM value is assumptive of more "pure data", probably at a
machine-generated rate many times faster than people can type.
The TTIMAX/TTPMAX limits are the critical limits - they determine when
the total datapath goes into an overrun condition (i.e., when the
datapath fails and loses data). They must be set sufficiently larger
than the corresponding TTIWRN/TTPWRN thresholds so that the total
datapath can "synchronize" and agree to come to a halt. In
particular, as described in "II" above they must be sufficiently large
to allow leeway for enough attempts at XOFFing the terminal (or "total
datapath", whatever happens to be out there) to ensure that at least
one XOFF works and the terminal stops sending input. The worst
(network) case would be a full (TTYMIC-sized) message just received,
and another full message's worth of data in the remote by the time the
buffer-low/XOFF message reaches it, so that each "retry leeway" would
require that the TTIMAX/TTPMAX limit be 2*TTYMIC larger than the
TTIWRN/TTPWRN threshold. In general, of course, the worst case is not
fully realized, so some further leeway is gained.
The default TTIMAX/TTPMAX values selected allow 5*TTYMIC total leeway.
The metric used in arriving at the 5*TTYMIC value was the observation
that (in the data rate tests described above, with the "system"
artifically loaded down so that the input program could only respond
at a 2.5Kb reading rate, and with TTYMIC=60) the host buffer low/XOFF
stood about a 10% chance of getting lost, requiring a second XOFF.
This second XOFF in its turn stood an equal chance of getting lost,
requiring a third XOFF about 1% of the time. In "many" minutes (about
20 actually) a fourth XOFF was never observed to be required, and no
characters were ever lost. (However it should also be pointed out
that ANY attempt to use a terminal line as a data path MUST be able to
tolerate loss and corruption of the character data - asychronous RS232
communications are notorious for being noisy and unreliable -
especially if routing over an unconditioned phone line, and very few
real-to-life applications obey the 50 foot maximum cable run allowed
for RS232 EIA links.)
The usual tradeoff applies for the TTIWRN/TTPWRN/TTIMAX/TTPMAX values
as well - the bigger the threshold, the more memory (chunks) are
required. SCNSER stores 12 characters per chunk, so a limit of 500
requires at least 42 chunks - and the overall system default is only 6
chunks per terminal! If more chunks are deemed necessary, the value
TTCHKN can be set via MONGEN to generate more chunks for the system.
Alternatively the monitor .EXE file can be patched (or the freshly
loaded but not yet started monitor can be patched via EDDT) by
changing the left half of location "TTCLST" to be the desired number
of chunks.
[CURE]
See attached FILCOMs.
********************************************************************************
EDIT 84 FOR ANF
[SYMPTOM]
Line blocks are usually too big.
[DIAGNOSIS]
Word LB.LCB is generated under the wrong conditional assembly.
It should be assembled only if there are asynchronous DDCMP lines on
the node, not just if there are DH11s or DZ11s .
[CURE]
Change the conditions to assemble LB.LCB correctly. See related
filcoms.
********************************************************************************
EDIT 85 FOR ANF
[SYMPTOM]
DN8X does not recover properly after a "? LOST MSG, INCONSISTENT
LENGTHS" message with DGUTS set.
[DIAGNOSIS]
In routine DDQSOL, we select an output line for a particular
message, increment the message count, and fall through to DDQ.O2. But
DDQ.O2 makes a call to DDDBCC to calculate the BCC and on an error
return with DGUTS set, prints the above message on the CTY and tosses
the message. This is fine except that it does not decrement the
message count.
[CURE]
Decrement the count. see related filcom.
********************************************************************************
EDIT 86 FOR ANF
[SYMPTOM]
Undefined macro when creating the station name when DFNAME is
undefined.
[DIAGNOSIS]
When DFNAME is undefined, an undefined macro is used to generate
the station name for DN87, DN20 and DN200s. The undefined macro is
OURNNM which is a symbol for our node number. It should use macro
OURSNM.
[CURE]
Use macro OURSNM to generate the station name. See related
filcom.
********************************************************************************
EDIT 87 FOR ANF
[SYMPTOM]
Useless symbol DNXXXX in macros .NXTDH and .NXTDZ in module
MACROS.P11.
[DIAGNOSIS]
DNXXXX should be DHXXXX for DH11s and DZXXXX for DZ11s.
[CURE]
Make the symbol meaningful. See related filcom.
********************************************************************************
EDIT 88 FOR ANF
[SYMPTOM]
Can't assemble both DH11s and DZ11s in the same -11 code.
[DIAGNOSIS]
DDBGEN gets conflicting LCB assignments.
[CURE]
Allow for the preceding DH11s (normally none) when correlating DZ11
terminals (or RDAs) to their respective LCBs.
********************************************************************************
EDIT 89 FOR ANF
[SYMPTOM]
Building an ANF10 front end with NLINES=0 causes the undefined
symbol LB.SCB. in module DNDCMP.P11.
[DIAGNOSIS]
The NLINES conditional should include routine DDDGIV in module
DNDCMP.P11.
[CURE]
Make the conditional include everything it should. Please see
related filcom.
********************************************************************************
EDIT 90 FOR ANF
[SYMPTOM]
Modem lines into an ANF front end can get hung up right away.
[DIAGNOSIS]
Before modem control states are completely done, a framing error
occurs. The modem control states become confused. The modem control
state becomes autobaud. A subsequent <CR> by the user succeeds and a
connection is made to the 10. The DEC-10 states are not flexible and
subsequent modem control statuses cause hangup.
[CURE]
Ignore framing errors unless the line is in "running unconnected"
through "running connected" mode. See related filcom. Please note,
this patch is inserted at different locations for version 7.01A and
7.02. The first filcom shows the change for version 7.01A, The second
filcom shows the change for version 7.02.
********************************************************************************
END OF ANF10-V23