home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 8 Other / 08-Other.zip / SDLCPO.ZIP / SDLCPOLL.TXT
Text File  |  1992-11-30  |  5KB  |  114 lines
  1. 02/06/92
  2. TITLE:   OS/2 EXTENDED EDITION - PU2.1 SDLC
  3.  
  4. SYMPTOM:
  5.  
  6.    Inability to activate a session to an OS/2 Communications Manager
  7.    workstation configured to function as a PU2.1.
  8.  
  9.    Message log reflects an ACS0119C entry.
  10.  
  11. ENVIRONMENT:
  12.  
  13.    PS/2 - All microchannel models
  14.    Host Communications Adapter - Multiprotocol Adapter
  15.  
  16.    Symptom appears when a SDLC link experiences polling delays caused by one
  17.    or more of the following:
  18.  
  19.    o   Slow link speed
  20.  
  21.    o   Too many PUs on link
  22.  
  23.    o   Communication errors on link
  24.  
  25.    o   Excessive link utilization
  26.  
  27.    o   Excessive network delays
  28.  
  29. CIRCUMVENTIONS:
  30.  
  31.    o   Increase line speed.
  32.  
  33.    o   Reduce number of PUs on link.
  34.  
  35.    o   Repeat PU2.1 addresses in 'Service Order Table' of NCP.
  36.  
  37.    o   Eliminate communication errors on link.
  38.  
  39.    o   Tune network
  40.  
  41.    o   Add '#Y' parameter to the SDLCDD.SYS statement in CONFIG.SYS.
  42.  
  43. ANALYSIS:
  44.  
  45.    The SDLCDD.SYS driver has a hard coded value for the 'Inactivity Timer.'
  46.  
  47. DETAIL:
  48.  
  49.    The '#Y' OS/2 SDLC device driver parameter is provided by OS/2 EE 1.3 and
  50.    ES Communications Manager products as a means for alleviating some of the
  51.    layer 2 performance problems encountered when activating PU2.1 nodes on a
  52.    SDLC multi-point line. The following is an explanation of how this anomaly
  53.    occurs:
  54.  
  55.    o   Before PU2.1 nodes enter a 'Contacted' state they must go through a
  56.        series of XID exchanges with the PU4/5 node for PU identification and
  57.        parameter negotiation. This overhead does not occur with PU2.0 nodes;
  58.        they directly enter a 'Contacted' state with a simple SNRM-UA exchange.
  59.  
  60.    o   The aforementioned XID overhead is not a problem in and of itself.
  61.        Link delays aggravate the problem by causing XID exchanges to go
  62.        through several 'cycles' before the nodes are ready to enter a
  63.        'Contacted' state.  Since all of the workstation nodes are Secondary
  64.        they are powerless to access the line until they are given a poll
  65.        response opportunity.
  66.  
  67.    o   Before a SDLC node enters Normal Response Mode (NRM, this is the
  68.        'Contacted' state) it is in Normal Disconnected Mode (NDM). NDM is the
  69.        equivalent of 'chaos' mode since there are no architected state machine
  70.        rules concerning timing for commands and responses.  The OS/2 SDLC
  71.        device driver does not generate XID responses; it waits for the
  72.        Configuration Services portion of the PU layer to build and supply the
  73.        XID responses. To ensure the link does not timeout while waiting for
  74.        the XID from Configuration Services, the SDLC driver will intentionally
  75.        wait for the next poll prior to sending the XID response.  This method
  76.        works fine except when there is excessive link polling delays which
  77.        results in the secondary node 'timing out' due to inactivity.
  78.  
  79.    The primary focus for creating an efficient multi-point environment should
  80.    be to balance the number of PUs per line with the amount of available
  81.    bandwidth (line speed). In addition to this, the '#Y' parameter provides
  82.    two additional benefits:
  83.  
  84.    1.  The SDLC Inactivity Timer gets set to 80 seconds. This prevents the
  85.        node from 'timing-out' during XID exchanges on heavily loaded or slow
  86.        multi-point lines. Normally, the inactivity timer is internally set to
  87.        40 seconds for most configurations.
  88.  
  89.    2.  The SDLC driver will wait for Configuration Services to provide the
  90.        XID, rather than waiting for the next poll. This reduces the number of
  91.        poll cycles it takes for a node to get into a 'Contacted' state since
  92.        the node does not wait for repolls. The '#Y' parm has a symbolic
  93.        meaning: the '#' stands for 'collision risk' and the 'Y' (or 'y') means
  94.        'yes' thus yielding 'collision risk = yes'; though this significantly
  95.        reduces node activation time, users of this parameter need to read and
  96.        understand the following concerns.
  97.  
  98. CONCERNS:
  99.  
  100.    o   The '#Y' parameter is not an all-encompassing fix for PU2.1 multi-point
  101.        environments. As previously stated, this parm, used in conjunction with
  102.        number-of-PUs-to-line speed ratio balancing, significantly alleviates
  103.        node activation performance problems at layer 2 (SDLC).  This parameter
  104.        in no way obviates potential performance problems that may or may not
  105.        be encountered at layer(s) 3+ (LU activation, etc.).
  106.  
  107.    o   Usage of this parameter means that the user, or network administrator,
  108.        assumes responsibility for ensuring that the poll timeout value of
  109.        primary SDLC node (usually a controller) is sufficient to allow the
  110.        workstation to issue the XID response. A poll timeout value of 1 second
  111.        or greater is strongly recommended.  Specifically this is the REPLYTO
  112.        statement in the GROUP definitions of NCP, the default is one second.
  113.  
  114.