  System Buffer Unavailable? 
 The Question is:
 
I am running DECnet Phase IV, and have noticed that my line counters
show "system buffer unavailable" increasing at an alarming
rate.
 
The documentation is unclear as to which network and account
parameters I should be looking at to correct this.
 
Can you suggest which things I should be looking at?
 
Peter
 
 
 The Answer is:
 
 
    Re: Below...
 
    &gt;I am running DECnet Phase IV, and have noticed that my line counters
    &gt;show "system buffer unavailable" increasing at an alarming
    &gt;rate.
    &gt;
    &gt;The documentation is unclear as to which network and account
    &gt;parameters I should be looking at to correct this.
    &gt;
    &gt;Can you suggest which things I should be looking at?
 
    The first item to check would be DECnet Executor Pipeline Quota.
 
    $ MCR NCP
    NCP&gt; sho exec pipeline quota
    NCP&gt; set exec pipeline quota 4032
    NCP&gt; def exec pipeline quota 4032
 
    There are several logical names that can affect DECnet performance,
    check the setting of:
 
      "NETACP$BUFFER_LIMIT" = "131070"
      "NETACP$ENQUEUE_LIMIT" = "600"
      "NETACP$EXTENT" = "16384"
      "NETACP$MAXIMUM_WORKING_SET" = "500"
      "NETACP$PAGE_FILE" = "25000"
 
    These are normally defined in sys$manager:sylogicals.com.
    (The values above are an example from a local Alpha system)
 
    e.g.
    $ define/system/exec NETACP$BUFFER_LIMIT 131070
 
 
    The high rate of "system buffer unavailable" could be due to
    hardware/network problems, or the CPU being very busy at high IPL, so
    the driver can't get around to servicing interrupts and emptying its
    buffers. I would encourage you to discuss this your local MCS
    hardware/software support folks.
 
    For some background on why 4032 is a good value for pipeline quota, read
    on.
 
 
    James	:-)
 
    
 
    DECnet Phase IV performance can be optimized by tuning the number of
    transmitter buffers to mesh with the speed and window size of the
    Ethernet receiver.
 
    For the majority of LAN based systems,  set DECnet Executor Pipeline
    quota to 4032.
 
    For example:
 
    $ MCR NCP
    NCP&gt; set exec pipeline quota 4032
    NCP&gt; define exec pipeline quota4032
 
    DECnet Phase IV Executor Pipeline quota usage
 
    The DECnet Executor Pipeline quota determines the maximum transmit
    window size. This is the maximum number of packets that will be
    transmitted before asking the receiver for an ACK (Implicit flow
    control).
 
    The maximum transmit window size is determined by dividing Pipeline
    quota by the Executor Buffer size.
 
    Although Ethernet packets can be 1498 bytes and FDDI packets can be 4468
    bytes, the default DECnet Executor Buffer size is 576. This is
    independent of the packet size sent on the wire.
 
    Given the default of 576 for exec_buffer_size:
 
    Max_transmit_window_size = exec_pipeline_quota/exec_buffer_size
 
    The initial transmit window size = ((Max_transmit_window_size / 3)*2)+1
 
    From there, the NSP flow control algorithms raise and lower transmit
    window size between 1 and Max_transmit_window_size.
 
    The minimum is 1 buffer, Pipeline quota = 576.
 
    The maximum is 40 buffers, Pipeline quota = 23040.
 
    Values for Pipeline quota larger than 23040 have no effect.
 
    In DECnet Phase IV there are several layers of buffers for Ethernet
    communication.
 
    The Ethernet Adaptor has a pool of buffers. This number is determined by
    the Adaptor and the driver, and cannot be tuned by a system or network
    manager.
 
    When incoming packets are dropped due to "Insufficient space in the
    Ethernet Adaptor", or "Insufficient speed of the Ethernet Adapter", you
    get either "Local Buffer Errors" or "Device Over run Errors". In this
    case the Ethernet Adapter itself is not fast enough or doesn't have
    enough onboard memory. This could be caused by design limitations of the
    adapter itself, or an I/O bound system where the adapter can't get at
    main system memory fast enough to empty its in ternal buffers.
 
    When packets are dropped due to "insufficient buffering" in the driver
    on the main system then you'll get "system buffer unavailable". This can
    be due to the CPU being very busy at high IPL, so the driver can't get
    around to servicing interrupts and emptying its buffers. This can be
    caused, or aggravated, by the system's total environment, such as memory
    usage, disk usage, maladjustment of system parameters, runaway
    applications, CPU speeds, etc..
 
    Since a system or network manager cannot increase the Ethernet Adaptor
    buffer pool, the only actions that can be taken in this case is to use a
    different (faster or more buffer space) Ethernet Adaptor on the
    receiving node, tune the VMS system to best advantage, understand the
    implications of memory and disk loading, and limit the "bursts" of
    packets other systems transmit to the the overrun system. For DECnet
    Phase IV, lowering the EXECUTOR PIPELINE QUOTA on transmitting nodes
    lowers the number of packets the overrun system needs to handle at a
    given time making communication smoother and more efficient.
 
 
    The next layer of buffers is a pool of buffers held for DECnet by the
    Ethernet driver. They specify the length of the line's receive queue.
    This pool of buffers can be tuned by the system or network manager by
    adjusting the setting of the LINE RECEIVE BUFFER count in the range of 1
    to 32.  When a significant user_buffer_unavailable count occurs, packets
    are being dropped by the Ethernet Driver because DECnet is not
    processing them fast enough.
 
    If the user_buffer_unavailable CIRCUIT counter increments, its because
    DECnet is not processing packets fast enough. When the
    user_buffer_unavailable LINE counter increments then it could be any
    Ethernet application that is not processing packets fast enough.
 
    A system or network manager can try to limit the user_buffer_unavailable
    count by increasing the LINE RECEIVE BUFFER count, or by limiting the
    "burstiness" of transmission by limiting the EXECUTOR PIPELINE QUOTA of
    transmitting nodes.
 
    The last set of buffers is the window size. DECnet Phase IV provides a 7
    buffer (hard coded) receive window per connection (link). This cannot be
    tuned by the system or network manager. The window size specifies the
    maximum number of frames that may be received before the data is
    transferred from system buffers to process buffers. The real limit can
    be lower. When 2 packets arrive without an associated receive IRP queued
    then a "backpressure" congestion control message is sent back telling
    the sending system to "XOFF" the logical link.
 
