| Title: | FDDI - The Next Generation |
| Moderator: | NETCAD::STEFANI |
| Created: | Thu Apr 27 1989 |
| Last Modified: | Thu Jun 05 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 2259 |
| Total number of notes: | 8590 |
Hi,
Can anyone explain the counters that a customer of mine is seeing ?
The customer has a 6000-320 with VMS V5.4-3 and a DEMFA in this
configuration:
------------
| 6000-320 |------
------------ |
|
|
-------- --------
| Conc |========| Conc |
-------- --------
|| ||
|| ||
-------- --------
| Conc |========| Conc |
-------- --------
|
|
----------
| Bridge |
----------
|
--------------------------------- Ethernet
When the DEMFA is physically disconnected from it's concentrator the
counters seem to latch at the highest possible unsigned integer, and
when it is reconnected only some counters return to normal, others do
not.
*** Example counter output from LATCP before disconnecting concentrator:
$ LATCP SHOW LINK DEMFA /COUNTER at 10-NOV-1991 11:57:02
Link Name: DEMFA
Device Name: _FXA4:
Seconds Since Zeroed: 1253
Messages Received: 15028 Messages Sent: 3070
Multicast Msgs Received: 12506 Multicast Msgs Sent: 250
Bytes Received: 2002279 Bytes Sent: 178543
Multicast Bytes Received: 1778954 Multicast Bytes Sent: 38112
System Buffer Unavailable: 0 User Buffer Unavailable: 0
Unrecognized Destination: 0 Data Overrun: 0
Receive Errors - Transmit Errors -
Block Check Error: No Excessive Collisions: No
Framing Error: No Carrier Check Failure: No
Frame Too Long: No Short Circuit: No
Frame Status Error: No Open Circuit: No
Frame Length Error: No Frame Too Long: No
Remote Failure To Defer: No
Transmit Underrun: No
Transmit Failure: No
FDDI Specific Counters
----------------------
Ring Initializations Initd: 0 Traces Initiated: 0
Ring Initializations Rcvd: 1 Traces Received: 0
Directed Beacons Received: 0 Ring Beacons Initiated: 0
Connections Completed: 0 Link Errors: 0
Duplicate Tokens Detected: 0 Dup Addr Test Failures: 0
Ring Purge Errors: 0 FCI Strip Errors: 0
LCT Rejects: 0 LEM Rejects: 0
Elasticity Buffer Errors: 0 MAC Frame Count: 101347391
MAC Error Count: 0 MAC Lost Count: 0
**** Link disconnected ****
$ LATCP SHOW LINK DEMFA /COUNTER at 10-NOV-1991 11:57:05
Link Name: DEMFA
Device Name: _FXA4:
Seconds Since Zeroed: 0
Messages Received: 4294967295 Messages Sent: 4294967295
Multicast Msgs Received: 4294967295 Multicast Msgs Sent: 4294967295
Bytes Received: 4294967295 Bytes Sent: 4294967295
Multicast Bytes Received: 4294967295 Multicast Bytes Sent: 4294967295
System Buffer Unavailable: 4294967295 User Buffer Unavailable:4294967295
Unrecognized Destination: 4294967295 Data Overrun: 4294967295
Receive Errors - Transmit Errors -
Block Check Error: Yes Excessive Collisions: Yes
Framing Error: Yes Carrier Check Failure: Yes
Frame Too Long: Yes Short Circuit: Yes
Frame Status Error: Yes Open Circuit: Yes
Frame Length Error: Yes Frame Too Long: Yes
Remote Failure To Defer: Yes
Transmit Underrun: Yes
Transmit Failure: Yes
FDDI Specific Counters
----------------------
Ring Initializations Initd: 4294967295 Traces Initiated: 4294967295
Ring Initializations Rcvd: 4294967295 Traces Received: 4294967295
Directed Beacons Received: 4294967295 Ring Beacons Initiated: 4294967295
Connections Completed: 4294967295 Link Errors: 4294967295
Duplicate Tokens Detected: 4294967295 Dup Addr Test Failures: 4294967295
Ring Purge Errors: 4294967295 FCI Strip Errors: 4294967295
LCT Rejects: 4294967295 LEM Rejects: 4294967295
Elasticity Buffer Errors: 4294967295 MAC Frame Count: 4294967295
MAC Error Count: 4294967295 MAC Lost Count: 4294967295
**** link reconnected ****
$ LATCP SHOW LINK DEMFA /COUNTER at 10-NOV-1991 11:57:15
Link Name: DEMFA
Device Name: _FXA4:
Seconds Since Zeroed: 1266
Messages Received: 4294967295 Messages Sent: 4294967295
Multicast Msgs Received: 4294967295 Multicast Msgs Sent: 4294967295
Bytes Received: 359043 Bytes Sent: 4294967295
Multicast Bytes Received: 900857 Multicast Bytes Sent: 4294967295
System Buffer Unavailable: 0 User Buffer Unavailable: 0
Unrecognized Destination: 0 Data Overrun: 0
Receive Errors - Transmit Errors -
Block Check Error: No Excessive Collisions: No
Framing Error: No Carrier Check Failure: No
Frame Too Long: No Short Circuit: No
Frame Status Error: No Open Circuit: No
Frame Length Error: No Frame Too Long: No
Remote Failure To Defer: No
Transmit Underrun: No
Transmit Failure: No
FDDI Specific Counters
----------------------
Ring Initializations Initd: 0 Traces Initiated: 0
Ring Initializations Rcvd: 4294967295 Traces Received: 0
Directed Beacons Received: 0 Ring Beacons Initiated: 0
Connections Completed: 4294967295 Link Errors: 0
Duplicate Tokens Detected: 0 Dup Addr Test Failures: 0
Ring Purge Errors: 0 FCI Strip Errors: 0
LCT Rejects: 0 LEM Rejects: 0
Elasticity Buffer Errors: 0 MAC Frame Count: 4294967295
MAC Error Count: 0 MAC Lost Count: 0
1. The FXDRIVER of VMS V5.4-3, standard base level, was used:-
Image Identification Information
image name: "FXDRIVER"
image file identification: "X-16"
link date/time: 4-SEP-1991 15:09:47.09
linker identification: "05-05"
2. The LTDRIVER used was:-
Image Identification Information
image name: "LTDRIVER"
image file identification: "V6.0-312A"
link date/time: 10-OCT-1991 12:07:11.82
linker identification: "05-05"
Any ideas ?
Alan Lloyd, TSC Basingstoke.
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 395.1 | a hunch | STAR::SALKEWICZ | It missed... therefore, I am | Mon Nov 18 1991 12:22 | 10 |
I believe that when the link is disconnected, the device/driver
will not return valid values for the counters. In fact, I believe
the buffer is empty on the $QIO request. The application that is
reading the counters (what application is this?) may be misinterpreting
the buffer/information/lack of counters being returned.
I'm not at all sure about this. Its just a hunch.
/Bill
| |||||
| 395.2 | thanks | KERNEL::LLOYDA | Don't worry... Be Happy ;^) | Mon Nov 18 1991 12:43 | 9 |
Bill,
These counters are coming from LATMASTER, LTDRIVER. Presumably we should
see similar NCP counters against the line.
If what you say is correct maybe I should post a note in LATMASTER as
well...
Alan.
| |||||
| 395.3 | KONING::KONING | Paul Koning, NI1D | Mon Nov 18 1991 12:47 | 4 | |
Hm, counters are supposed to be valid independent of the state of the device. Oh well, fixed in Phase 5, perhaps? paul | |||||
| 395.4 | ... | STAR::SALKEWICZ | It missed... therefore, I am | Mon Nov 18 1991 17:22 | 12 |
How about,.. fixed as soon as you plug the cable back in?
:-)
Its currentyly a limitation of the driver implementation. The driver
enters a state called "FDDI Ring Unavailable" ,.. during which time all
"control" requests (which includes counters at the moment) are passed
back in error. We could start letting counters through even in this
state. I'll look into it. For now (V5.4-3, V5.5) you are stuck with
that behavior. Sorry
/Bill
| |||||
| 395.5 | KONING::KONING | Paul Koning, NI1D | Mon Nov 18 1991 18:31 | 7 | |
There are two other interesting anomalies: 1. It seems that the counters are zeroed when the connection is plugged in. 2. In the last list of counters in .0, the multicast bytes received count is greater than the bytes received count. paul | |||||
| 395.6 | help | KERNEL::LLOYDA | Don't worry... Be Happy ;^) | Tue Nov 19 1991 13:53 | 3 |
What kind of QIO do I need to use ? Any examples ?
Alan.
| |||||
| 395.7 | HELP!!! | KERNEL::LLOYDA | Don't worry... Be Happy ;^) | Wed Dec 04 1991 05:36 | 7 |
The customer has received the driver source code and he cannot see any
call which will detect the ring failure. Where is the call ?
This is very urgent.
Alan.
| |||||
| 395.8 | NAC::THOMAS | The Code Warrior | Wed Dec 04 1991 08:42 | 1 | |
Ring failures are communciated trough the unsolicited event ring. | |||||
| 395.9 | reality check | STAR::SALKEWICZ | It missed... therefore, I am | Thu Dec 05 1991 10:56 | 9 |
I have yet to see any entries in the UNsolicited ring. That may be
where the device documentation says that ring failures are reported,
but in reality, nothing ever gets reported in the unsolicited ring.
There is a bit in the XPST register callled "FRA". If the customer
see the driver reacting to this bit and changing states when
the ring becomes available/unavailable.
/Bill
| |||||
| 395.10 | KONING::KONING | Paul Koning, NI1D | Thu Dec 05 1991 11:23 | 5 | |
You probably haven't had any ring failures. Available vs. unavailable is NOT a "failure". Things like stuck-beaconing (trace initiated) would be failures, but those aren't likely to happen on normal networks. paul | |||||
| 395.11 | Slowdown! | KERNEL::LLOYDA | Don't worry... Be Happy ;^) | Fri Dec 06 1991 04:48 | 4 |
Sorry, but I don't understabd most of the terms you are using ! could
someone briefly exaplain them please.
al.
| |||||
| 395.12 | KONING::KONING | Paul Koning, NI1D | Fri Dec 06 1991 12:20 | 8 | |
At the risk of sounding snotty... if you don't understand these terms, then you almost certainly have no need to modify the driver to do anything different when these events happen! Apart from that: look in the FDDI primer, it should explain most or all of these things. paul | |||||