HP3000-L Archives

March 2000, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
James Hofmeister <[log in to unmask]>
Reply To:
Date:
Thu, 9 Mar 2000 15:25:30 -0500
Content-Type:
text/plain
Parts/Attachments:
NS (58 lines)
Hello Friends,

Re: NS question

------------------------------------------------Al Nizzardini writes--
What would cause NS Xport 1536 Inbound Buf Pool to fill up and cause
us not to log on via VT-mgr or Telnet. Tha max was set to 170 and I
bump it up to 341 but it just brought me time before it reached it
limit.
------------------------------------------------Al Nizzardini writes--

I can say with good confidence the problem is not likely with the
Buffer Manager (procedure calls that read and write to the inbound
buffer pool), or with the Link drivers (which perform Direct Memory
Access "DMA" writes to this pool).  The other interfaces to this
buffer pool are TCP, UDP & some less well known protocols.

This "NS Xport 1536 Inbound Buf Pool" is a memory area shared by all
of the link cards that receive frames of a 1536 size (this is a
Ethernet or 802.3 Frame with some overhead bytes).

The place where I and the Response Center start trouble shooting a
problem like this is to look for 2 possible/likely problems:

1. Check for problems on the network cable.  This is easily performed
   by a :linkcontrol @;status=all and reviewing the statistics.
   Be on the lookout for spikes (network storm).

2. Check for possible socket based application problems.  This is
   best performed when the problem is seen "network is hung up" by
   using the nettool ":nettool.net.sys;info="res;di;quit" to monitor
   the "NS Xport 1536 Inbound Buf Pool" utilization and then one by
   one start terminating applications which use sockets on the 3000,
   and between the stop of each application again use the nettool
   command to see if the utilization has dramatically dropped.  When
   the utilization drops dramatically, you have identified the rogue
   network application.   Note: :SHOWCONN can help you identify which
   applications have network sockets open. Of course one of the first
   questions to ask is "what changed since this problem started?".

A third possibility is performance.  It is not difficult to drive a
inbound buffer pool full condition by starting up multiple FTP file
transfers from a big machine (my "HPCPUNAME = SERIES 959-200" as an
example) to a slow small machine (my "HPCPUNAME = SERIES 917LX" as
an example). In this case the "NS Xport 1536 Inbound Buf Pool" full
condition is not necessarily a bad thing, the overflow "discard" mode
is protecting the 3000 from crashing and robust protocols TCP as an
example can handle intermittent cases of discards.

I hope this helps.

Regards,

James Hofmeister
Hewlett Packard
Worldwide Technology Network Expert Center
P.S. My Ideals are my own, not necessarily my employers.

ATOM RSS1 RSS2