Trailing-Edge
-
PDP-10 Archives
-
BB-H348C-RM_1982
-
swskit-v21/documentation/32k-systems.mem
There are no other files named 32k-systems.mem in the archive.
---------------
|d|i|g|i|t|a|l| INTEROFFICE MEMORANDUM
---------------
TO: DECnet Users DATE: 4-Mar-80
FROM: NCSS
EXT: HOTLINE (6492)
LOC/MAIL STOP: MR1-2/H22
SUBJ: The use of 32K DN20's
DECnet-20 V3.0 WILL NOT RUN in a 32K DN20. The following
information describes DECnet-20 V2.0 or V2.1.
The 32K DN20, supporting one DUP, is very short on buffer
space. A pontential reliability problem exists because of this
shortage. If the DUP is using a noisy or moderately noisy line
then some buffers may have to be retained for retransmission.
When this happens, buffer space can get so low that the MCB will
automatically shut the line down and allow it to restart after a
few moments. When this problem occurs The operator will see at
the console:
Node BLAH Offline
Node BLAH Online
The user may see his link hang, or he may get an IO error message.
The problem can be solved by lowering the demand on buffers.
This can be done using any combination of the following.
1) Use a line with fewer errors.
2) Lower the number of buffers sitting in the MCB by setting
the flow control count in the remote node to fewer messages or
segments. If the remote node is a TOPS20 system see 3) for
patches.
3) Lower the number of buffers sitting in the MCB by setting
the flow control count in the local node lower. In NSPSRV patch
as follows where 5 and 3 are smaller than 11 and 10. Experiment
with smaller values if necessary.
$GET SYSTEM:MONITR.EXE
$START 140
NSPSRV$:
STMXDF/ MOVEI T2,11 MOVEI T2,5
Page 2
STMXDF+3/ MOVEI T2,10 MOVEI T2,3
^Z
$SAVE
4) Lower the number of buffers sitting in the MCB by limiting
the number of messages queued to the DTE at the local node. In
NSPSRV patch as follows:
$get system:MONITR.EXE
$ST 140
NSPSRV$:
STMXDF+5/ MOVEI T2,10 MOVEI T2,3
^Z
$SAVE