[Search for users]
[Overall Top Noters]
[List of all Conferences]
[Download this site]
| Title: | DEC Network Integration Server (DECNIS) |
| Notice: | Please read note 1 to use this conference effectively |
| Moderator: | MARVIN::WELCH |
|
| Created: | Wed Sep 18 1991 |
| Last Modified: | Thu Jun 05 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 3660 |
| Total number of notes: | 15082 |
3545.0. "Further FRBS Discard Clarification needed" by OHFSS1::MALOTT (Lost in a Maze of DecNis') Mon Feb 17 1997 12:57
I wonder if I could get some clarification on FRBS channel "discarded
frames" Note 3240 seems a bit cloudly in light of the NCL help
definition of same. The following is the Help on FRBS chann counters;
o CRC ERRORS
Specifies the number of CRC errors.
o CREATION TIME
Specifies the time at which the CHANNEL entity was created.
o DISCARDED FRAMES
Specifies the number of times a received frame is discarded
because it contained an error.
o FRAMES RECEIVED
Specifies the number of frames received on this channel.
o FRAMES SENT
Specifies the number of frames sent on this channel.
o IP CONGESTION DISCARDS
Specifies the number of IP PDUs discarded because of
congestion.
o IP FRAGMENTS CREATED
Specifies the number of IP fragments created.
o IP PDUS FORWARDED
Specifies the number of IP PDUs forwarded.
o IP PDUS FRAGMENTED
Specifies the number of IP PDUs fragmented.
o IP PDUS RECEIVED
Specifies the number of IP PDUs received.
o IP PDUS RECEIVED DISCARDS
Specifies the number of IP PDUs discarded.
o IP PDUS SENT
Specifies the number of IP PDUs sent.
o LAST STATE CHANGE TIME
Specifies the time at which the channel entered its
current operational state.
o MANAGEMENT FRAMES RECEIVED
Specifies the number of Status Procedure messages received.
o MANAGEMENT FRAMES SENT
Specifies the number of Status Procedure messages sent.
o MANAGEMENT OCTETS RECEIVED
Specifies the number of octets received in Status Procedure
messages.
o MANAGEMENT OCTETS SENT
Specifies the number of octets transmitted in Status Procedure
messages.
o MANAGEMENT PROTOCOL TRANSITIONS
Specifies the number of Management Protocol State
transitions.
o OCTETS RECEIVED
Specifies the number of octets received on this channel.
o OCTETS SENT
Specifies the number of octets sent on this channel.
o OSI CONGESTION DISCARDS
Specifies the number of OSI data and error report PDUs discarded
because of congestion.
o OSI PDUS FORWARDED
Specifies the number of OSI data and error report PDUs forwarded.
o OSI PDUS FRAGMENTED
Specifies the number of OSI data PDUs fragmented.
o OSI PDUS RECEIVED
Specifies the number of OSI data and error report PDUs received.
o OSI PDUS RECEIVED DISCARDS
Specifies the number of OSI data PDUs discarded because
segmentation was required but was not permitted in the
header.
o OSI PDUS SENT
Specifies the number of OSI data and error report PDUs
sent.
o SERVICE ERRORS
Specifies the number of times service-affecting conditions
were detected. One method of determining such a condition
is defined in T1.617 - 1991 Annex D.
o STATE TRANSITIONS
Specifies The number of times the channel has changed its
state.
o TIME OF ERROR
Specifies the time the last error occurred.
****************************************************************
Note 3240 seems to indicate frames were discarded due to an packets
arriving bound for a link that was too full to handle them all. Yet
the help file seems to indicate something different (ie errored packets
rec'vd). Does anyone know whether the definition in the Help file is
wrong or, are there two perspectives of the "discarded frames" (ie IP,
OSI congestion discards and discarded frames)?
We currently have a link (64K Access, 16K CIR) that is getting a gradual
increase of "discarded frames", slow response to apps, but no ip or osi
congestion discards and very few (7) CRC errors. Knowing either the
'Help' characteristic is wrong or right will help in troubleshooting
this issue...
Thank you in advance for any help...
John Malott
| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 3545.1 | probably data for an unknown DLCI | MARVIN::RIGBY | No such thing as an alpha beta | Tue Feb 18 1997 09:05 | 15 |
| The DISCARDED FRAMES counter is incremented for three separate reasons in the
current code. In order of decreasing probability...
1) when an incoming frame has a bad DLCI, ie for a channel that has not been
configured
2) when an incoming FR UNI (also known as LMI) packet has any error - sequence
error or other information element error.
3) when an incoming frame is for a known DLCI but there is no datalink client to
give it to.
In each case the bad frame is stored in the channel status attribute ERROR DATA.
You could try using DTF/PIPE/TYPE=fr/FULL "<hexdata>" to decode it.
|
| 3545.2 | Thanx again... | OHFSS1::MALOTT | Lost in a Maze of DecNis' | Tue Feb 18 1997 13:55 | 10 |
| John,
Once again, thank you for your quick respnse. I'll post what I find
here for infomation's sake.
Best Regards,
John Malott
|