Google
 

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