[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference netcad::hub_mgnt

Title:DEChub/HUBwatch/PROBEwatch CONFERENCE
Notice:Firmware -2, Doc -3, Power -4, HW kits -5, firm load -6&7
Moderator:NETCAD::COLELLADT
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

14.0. "Strange behavior of DECMR may be ?" by LEMAN::BRUNNER () Mon Dec 16 1991 05:16

	Hi all, anybody heard about this ?

	Customer is testing a configuration including a DECHUB90 backplane 
	configured with DECbridge90 (DEWGB) and two DECrepeater90C (DECMR).

	Everything works fine with DEC equipment (DS5000, DEMPR, LB150)
	But with NON-DEC equipment some frames larger than 500 bytes are
	getting lost. Customer analysis shows that with such packets the
	DECMR is loosing "synchronization" and packet gets filled with a
	string of "010101" bits. The DEWGB drops the packets because of
	wrong CRC, but no counter in the bridge reports dropped packets.
	Shouldn't the bridge increment a discarded frames counters in this
	case ? Is the same happening with DECrepeater90T ?

	Also found by customer that if you remove the transceiver cable for
	topology changes the DECbridge90 hangs.

	Cross posted in RBMS_LANBRIDGE100
	Best regards
	Field Support Group Walter
T.RTitleUserPersonal
Name		DateLines
14.1DECbridge 90 does not count FCS errorsEMDS::SEAVERLENAC Net Mgnt Mktg 223-4573Tue Dec 17 1991 12:2414
From:	PRNSYS::LOMICKAJ "Jeffrey A. Lomicka, Maynard MA, DTN 223-4031  17-Dec-1991 1053" 17-DEC-1991 10:56:14.88
To:	KALI::MEMIT::FORREST
CC:	LEMAN::BRUNNER,EMDS::SEAVER
Subj:	RE: Customers seeing odd behavior...

The DEcbridge 90 cannot count FCS errors due to a problem in the DECbridge gate 
array that miscounts these errors when they didn't really occur.  For similar 
reasons, it can't report framing errors or remote failure to defer.

A plan exists to revise the gate array to correct for these problems.  This is 
not linked to the implementation of RBMS.  The RBMS code, when running on new 
hardware (if or when it exists), will report these counters, but running on old 
hardware, will not.
14.2POTS::VISSERMon Dec 23 1991 10:4436
    re.: note 14.0, first a comment, then a possible answer, third, some
    advice:
    
    1. when asking for an answer a problem such as described in 14.0,
    provide as much information regarding the problem as possible.  This
    should include a description of the topology, the communicants, and the
    symptom.  For example, 
    
    	"Everything works fine with DEC equipment (DS5000, DEMPR, LB150)
	But with NON-DEC equipment some frames larger than 500 bytes are
	getting lost."
    
    What is one supposed to imagine is going on here?  Where are the frames
    coming from, and where are they destined?
    
    2. This sounds like a "problem" that we have discovered with the new
    (90C and 90T) repeaters, which isn't really a repeater problem; these
    new devices are less tolerant of out-of-specification timebases in PLS
    implementations than previous repeaters.  Note well, however, that if a
    station is operating within the Ethernet or 802.3 specs., it will work
    with a 90C or 90T.  If a node transmits outside the spec.,
    specifically, with a slow or fast clock, all bets are off.  Note also
    that the slow clock may cause other perhaps less catastrophically
    expressed network problems, such as the ability to communicate with
    only a sub-set of the nodes on the net, and perhaps it is time to cull
    these transgressors from the installation.
    
    3. Don't panic.  When something "goes wrong," don't simply blame the
    newest piece of gear.  Procede deliberately and methodically towards
    the answer.  Don't indict early.  Gather data, avoid ambiguity, and
    communicate.
    
    Thanks,
    
    John Visser