| 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 |
The DECbridge 6xx V1.2 counts some receive and transmit errors
TWICE. Is this known and solved in the upcoming V1.3 release?
Also, sometimes the summary counter is incremented but none of
the specific ones (no specific late collision counter?).
When is 1.3 Firmware available?
counters where taken with mcc 1.2.
name lin yy-mm-dd time | bfr msfr of fe | tef cl cle le cptf
.6410 L_3 92-10-18 13:16:13| 433 0 0 207 | 89 17 4 2 16
.6410 L_3 92-10-19 09:12:19| 433 0 0 207 | 89 17 4 2 16
.6410 L_3 92-10-19 13:11:33| 433 0 0 207 | 89 17 4 2 16
.6410 L_3 92-10-20 09:07:25| 433 0 0 207 | 91<-? 17 5 2 16
.6410 L_3 92-10-20 13:06:38| 433 0 0 207 | 91 17 5 2 16
.6410 L_3 92-10-21 09:02:07| 433 0 0 207 | 92<-? 17 6 2 16
.6410 L_3 92-10-21 13:01:13| 433 0 0 207 | 92 17 6 2 16
.6410 L_3 92-10-22 08:56:46| 436<-? 0 1 208 | 93<-? 17 6 2 16
.6410 L_3 92-10-22 12:55:53| 436 0 1 208 | 93 17 6 2 16
.6410 L_3 92-10-23 08:51:13| 436 0 1 208 | 93 17 6 2 16
.6410 L_3 92-10-23 12:50:19| 436 0 1 208 | 93 17 6 2 16
name lin yy-mm-dd time | bfr msfr of fe | tef cl cle le cptf
.6410 L_3 92-10-24 08:45:22| 436 0 1 208 | 93 17 6 2 16
.6410 L_3 92-10-24 12:44:24| 438<-? 0 1 209 | 93 17 6 2 16
.6410 L_3 92-10-25 08:39:21| 438 0 1 209 | 93 17 6 2 16
.6410 L_3 92-10-25 12:38:22| 438 0 1 209 | 93 17 6 2 16
.6410 L_3 92-10-26 08:33:14| 441<-? 0 2 210 | 94<-? 17 6 2 16
.6410 L_3 92-10-26 12:32:08| 441 0 2 210 | 94 17 6 2 16
.6410 L_3 92-10-27 08:26:44| 441 0 2 210 | 94 17 6 2 16
.6410 L_3 92-10-27 12:25:34| 441 0 2 210 | 94 17 6 2 16
.6410 L_3 92-10-28 08:19:59| 441 0 2 210 | 94 17 6 2 16
.6410 L_3 92-10-28 12:18:55| 445<-? 0 2 212 | 94 17 6 2 16
.6410 L_3 92-10-29 08:13:13| 448<-? 0 3 212 | 95<-? 17 6 2 16
bfr = bad frames received (summary counter)
msfr= multicast source frames received
of = oversize frames
fe = framing errors
tef = transmit error frames (summary counter)
cl = carrier lost
cle = collision limit exeeded
le = lenght error
cptf= collision presence test failed
greg= :-(
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 823.1 | 1.3 FT too | ZUR01::HOTZ | Gregor, CS, NaC Support, Schweiz | Thu Jan 21 1993 10:27 | 18 |
I got hold of 1.3 FT for the DB628. On port 2 I connected a
HP4972 analyzer to send "bad" frames; no other stations.
frame #1: 2000 Bytes, good FCS Line counter: bfr +1 of +1
#2: 2000 Bytes, bad FCS : bfr +2 of +1
According to the ELMS and MCC manuals, bfr (bad frames received)
counts CRC errors. Frame #1 has a good CRC.
With frame #2, we get even 3 increments. But the frame has only 2
errors. I would expect only of (oversized frame) to be
incremented. bfr isn't an error summary counter, isn't it?
Where can I QAR this? This makes our LANs look worse then they
are and causes unnecessary problem calls.
greg.
| |||||
| 823.2 | Couldn't reproduce | QUIVER::WALTER | Mon Jan 25 1993 18:46 | 15 | |
Re: .1
I tried the test outlined in reply .1 with a bridge running V1.3FT,
and found that frame #1 (good FCS) was not counted in Bad Frames
Received, and frame #2 (bad FCS) was counted once for each frame.
So, I was not able to replicate the problem.
Re: .0
I'm not sure if the errors add up the way you expect them to. I'll
look into it.
Regards,
Dave Walter
| |||||
| 823.3 | 2000 byte frame not too long? | ZUR01::HOTZ | Gregor, CS, NaC Support, Schweiz | Wed Jan 27 1993 05:09 | 20 |
The V1.3FT I got hold of has a date of 23-NOV-1992 16:57:41.00.
Can I test a later version?
How was frame #2 (TOO LONG + bad FCS) counted? It should be
counted as frame too long, only, no matter whether it has a good
or bad fcs or is misaligned, I think.
From the counters in .0 I got the impression that bfr and
tef were summary counters. But the manuals (elms, decmcc) don't
say so.
Btw, why is there no �remote failure to defere� (late collision)
counter? I thought the LANCE chip does report it.
...and as a side remark, I think Bad is bad. There is a �Bad frames
Received� and a �Bad hello limit exeeded� counter. The 1st means,
there was a frame with an invalid CRC received, the 2nd means,
Hellos came in from the wrong direction but the CRC was valid.
regards, greg.
| |||||