| Title: | DEChub/HUBwatch/PROBEwatch CONFERENCE |
| Notice: | Firmware -2, Doc -3, Power -4, HW kits -5, firm load -6&7 |
| Moderator: | NETCAD::COLELLA DT |
| Created: | Wed Nov 13 1991 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 4455 |
| Total number of notes: | 16761 |
We currently have two decserver products logging an excessive amount of
User and System Buffer Unavailables at the Decserver. They are A
decserver 90 TM and a decserver 900 TM.
I thought that typically, System Buffer Unavailables meant the
interface had data to pass to the system but there were no rcv ring buffers
available within the driver at that time. And User Buffer Unavailables
meant that the application had not allocated enough buffer space to
handle traffic arriving destined for the application. But, these are
explanations relating to host systems (ie VAXes, Alphas, etc..)
How does this relate to Decservers?
These 2 decservers are used for IP (Telnet) connections to host system
consoles and back to a Polycenter Console system used for monitoring in
the following rough connection configuration.
--------- ---- remote sys console port ----------
| | | |---------------------------------| |
| | | | port n | |
| | | | | |
| | PolyCenter | | Decserver 9xTM | |
----|---- Rem Console --|- ----------
| | Remote System
| |
>------------------------------<
EtherNet Connection
The 2 decservers in question periodically drop their telnet connection
between the remote system and the Polycenter Console system. The only
thing that we seem to have to go on is the User and System Unavailable
counters incrementing at regular intervals.
DS 900 TM:
Network Access SW V1.5 for DS900TM BL95-33 ROM V5.0-0 Uptime: 20
18:27:59
Address: 08-00-2B-A2-A4-25 Name: GLTS01 Number: 0
Identification:
Circuit Timer: 80 Password Limit: 3
Console Port: 1 Prompt: Local>
Inactivity Timer: 30 Queue Limit: 100
Keepalive Timer: 20 Retransmit Limit: 8
Multicast Timer: 30 Session Limit: 64
Node Limit: 200 Software: WWENG2
Service Groups: 0
Enabled Characteristics:
Announcements, Broadcast, Dump, Lock
Network Access SW V1.5 for DS900TM BL95-33 ROM V5.0-0 Uptime: 20
18:29:06
Seconds Since Zeroed: 1794546 Frames Sent, 1 Collision: 197
Bytes Received: 4294967295 Frames Sent, 2+ Collisions: 204
Bytes Sent: 22953655 Send Failures: 0
Frames Received: 58257000 Send Failure Reasons: 0000000000
Frames Sent: 338260 Receive Failures: 0
Multicast Bytes Rcv'd: 2491509234 Receive Failure Reasons:0000000000
Multicast Bytes Sent: 751599 Unrecognized Destination: 0
Multicast Frames Rcv'd: 36374497 Data Overrun: 0
Multicast Frames Sent: 6138 User Buffer Unavailable: 1653134
Frames Sent, Deferred: 3731 System Buffer Unavailable: 8825
Messages Received: 2239 Duplicates Received: 0
Messages Transmitted: 2148 Messages Re-Transmitted: 7
Solicitations Accepted: 735 Illegal Messages Rcv'd: 0
Solicitations Rejected: 0 Illegal Slots Rcv'd: 0
Multiple Node Addresses: 9809 Illegal Multicasts Rcv'd: 0
DS 90 TM:
Network Access SW V1.5 for DS90M BL95-32 ROM 4.1 Uptime: 69
08:54:55
Address: 08-00-2B-B3-E7-25 Name: GLTS02 Number: 0
Identification:
Circuit Timer: 80 Password Limit: 3
Console Port: 1 Prompt: Local>
Inactivity Timer: 30 Queue Limit: 100
Keepalive Timer: 20 Retransmit Limit: 8
Multicast Timer: 30 Session Limit: 64
Node Limit: 200 Software: MNENG2
Service Groups: 152
Enabled Characteristics:
Announcements, Broadcast, Dump, Lock
Local> sh server count
Network Access SW V1.5 for DS90M BL95-32 ROM 4.1 Uptime: 69
08:55:02
Seconds Since Zeroed: 5993702 Frames Sent, 1 Collision: 158
Bytes Received: 4294967295 Frames Sent, 2+ Collisions: 199
Bytes Sent: 22512263 Send Failures: 0
Frames Received: 193820913 Send Failure Reasons: 0000000000
Frames Sent: 308096 Receive Failures: 0
Multicast Bytes Rcv'd: 4294967295 Receive Failure Reasons: 0000000000
Multicast Bytes Sent: 16883733 Unrecognized Destination: 0
Multicast Frames Rcv'd: 115388639 Data Overrun: 0
Multicast Frames Sent: 211586 User Buffer Unavailable: 4086122
Frames Sent, Deferred: 3061 System Buffer Unavailable: 28691
Messages Received: 32 Duplicates Received: 0
Messages Transmitted: 30 Messages Re-Transmitted: 0
Solicitations Accepted: 0 Illegal Messages Rcv'd: 0
Solicitations Rejected: 0 Illegal Slots Rcv'd: 0
Multiple Node Addresses: 32953 Illegal Multicasts Rcv'd: 0
Thanks in advance for any assistance,
jcm
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 3780.1 | Don't believe much LAT here | OHFSS1::MALOTT | Lost in a Maze of DecNis' | Wed Aug 07 1996 19:03 | 11 |
I found some expanation in decserver notes file to User Buffer
Unavailables. There explanation seems to say 90% of User Buffer
Unavail are due to discarding LAT service announcements in favor of
more important traffic. However, to my knowledge this customer Network
does not have an extraordinarily large amount of LAT traffic
(Converting to NT/Win95 platforms using TCP/IP). .: I am still
perplexed as to what could be causing this issue.
Any help appreciated.
jcm
| |||||
| 3780.2 | KEIKI::WHITE | MIN(2�,FWIW) | Wed Aug 07 1996 19:05 | 27 | |
Half the frames received are multicast and on one server it
averages out to 2 multicast frames per second over the life of this
boot.
The book says -
"User Buffer Unavailable"
Number of times the access server did not have a user
buffer available to store an incoming frame that passed through the
system buffer. This counter should accumulate at a rate of less than
two counts per day. Note that the value of this counter could be high
if there are a large number of LAT service multicast announcements
on the network. Also, it is normal to experience some errors when
nodes are added to the Ethernet.
What is the average and weighted max multicast rate on this network
when the user buffer unavailables are incrementing?
And are they LAT multicasts or TCP/IP multicasts/broadcasts
Also why do you have Multiple Node Addresses seen and
what is the current CPU % used when the user buffer unavailables are
increasing?
Bill
| |||||
| 3780.3 | IROCZ::D_NELSON | Dave Nelson LKG1-3/A11 226-5358 | Thu Aug 08 1996 12:14 | 13 | |
RE: .various If you don't have a significant rate of LAT service announcement multicasts on your LAN (measured in peak bursts, not daily averages) then you might be reasonably concerned about the User Buffer Unavailabe count. You should always be concerned about the System Buffer Unavailable count. Been experiencing any broadcast storms recently? Regards, Dave Nelson Tech Lead, Remote Access Software | |||||
| 3780.4 | alot of ARP's | OHFSS1::MALOTT | Lost in a Maze of DecNis' | Thu Aug 15 1996 12:34 | 19 |
Re: .3
Let me take a step back and describe the network here.
Decnis Routers as backbone serving FDDI rings with Lan segments bridged
off these. Routers seem to have ARP cache limitations and since they
support a large subnet, they (and other nodes)are ARP'g quite a bit.
This seems to account for the majority (65-75%) of multicast traffic at
these two decservers.
Again, the decservers soul purpose is to serve up
their ports as console ports to systems and then feed this back to
monitoring station via IP (Telnet). By latest count, the traffic theses
servers see is 50-65% multicast. Would this account for both types of
buffer unavailables?
Thanks in advance?
jcm :^)
| |||||
| 3780.5 | IROCZ::D_NELSON | Dave Nelson LKG1-3/A11 226-5358 | Thu Aug 15 1996 15:34 | 23 | |
RE: .4 > Would this account for both types of buffer unavailables? No. System Buffer Unavailable means that packets are arriving too fast for the software to service the hardware (LANCE Ethernet controller). Typically this is caused by burts of packets, e.g. 100 back-to-back broadcast packets on the LAN. Average traffic levels don't tell me much. Hence my comment about broadcast storms. User Buffer Unavailable means that the software decided to shed load (e.g. discard some of the LAT Multicasts) or the Network/Transport/Application layers are too congested and there aren't enough buffers to go around. I would not expect this of ARP, because it is processed at a pretty low layer in the code, but it's possible that under large bursts of packets, you could see the UBA count incremented because of ARP packets. Regards, Dave | |||||
| 3780.6 | Hope newer Decservers handle more multicast traffic | KEIKI::WHITE | MIN(2�,FWIW) | Mon Aug 26 1996 18:07 | 16 |
Back in the old DECSERVER-200 days more than 10 Multi/Broadcast
packets per seconds would cause these types of errors plus they
didn't have the code to toss packets so the end result was virtual
circuit timeouts.
I hope the newer decservers can at least process 5 times the
burst rate as previous decservers, so if your Network Sniffer shows
more than 50 Multicast/Broadcast packets per second at any time
SBU's could clock up and along with them UBU's as we discard packets
we cannot process in time.
You never mentioned what the DECSERVERS CPU % is during the
the times SBU's are clocking up.
Bill
| |||||
| 3780.7 | SW upgrade solved disconnects | OHFSS1::MALOTT | Lost in a Maze of DecNis' | Thu Aug 29 1996 12:32 | 15 |
Problem of intermittently dropping telnet connections back to
Polycenter monitor was solved by upgrading servers to:
BL10-40 V2.0 from BL09-39 V1.5.
However, multicast/total remains high and user & system buffer
unavailables continue to rise. Terminal servers are functioning fine
though.
I believe the incrementing UBU & SBU's are due to the almost 65%
multicast traffic on these particular LAN's (Large amount of
Client/Server uSoft IP).
Thanx for all the info,
jcm :^)
| |||||