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

Conference 7.286::fddi

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

406.0. "DEFEB port not 'breaking' quickly enough ?" by COMICS::WOODWARD (Smile!) Thu Nov 28 1991 10:40

Hi world,

A problem at a customer site prompted the following simple test which seems to
highlight a problem in our DecBridge 500. Comments welcome....


	------------		 -----------
	|  DB 500  |..FDDI LINK..|  DB500  | (customer has bridges connected
	------------		 -----------   to cons on dual ring)
	     |			       |
	     |			       |
	  ================================  Ethernet

	   ^^^			     ^^^
	Root bridge		backup (on ethernet port)

Test 1 used the thinwire connections on the DB500.

	a) the "T" was pulled out from the back of the bridge at time 0

	b) after 45 seconds the backup line became forwarding (watching the
	   lights and 'showing' time on a vms system - highly accurate eh ;-)

	c) a further 3 min 30 seconds later (ie total 4 min 15 sec from removing
	   the connector) the 'root' bridge stopped forwarding onto the 
	   (disconnected) ethernet and put the port into broken state
	   (led flashing).

Test 2 used the thichwire (aui) port connected to a drop cable. When the drop 
cable was removed the port went 'broken' after 20 seconds.

Question - Why should the thinwire port take so long to detect the absence
of the network connection ?


Steve

T.R	Title	User	Personal Name	Date	Lines
406.1	Transceiver Characteristics	QUIVER::POULIN		`Wed Dec 04 1991 14:43`	50
	Steve, One way the DECbridge 500 checks link integrity is to monitor transmission errors on the Ethernet. When the bridge counts ten consecutive "loss of carrier" errors (per packet error) the bridge conducts a link test, which employs the "external loopback test" mechanism of the Ethernet chip. So depending on traffic rate, the time interval to record ten consecutive loss of carrier errors will vary. A second way of checking link integrity is to monitor packet reception. If no traffic is received for the "no frame interval" (a manageable parameter that is set at the factor at 3 minutes) the link will be tested. Assuming the traffic rate is fairly equivalent in your two different tests, the above paragraph alone would not describe the difference in behavior of the bridge. The DECbridge 500 uses an integral transceiver chip (separate from the Ethernet chip) when the ThinWire port is selected. When no connection is made to a ThinWire segment, this integral transceiver "sees" carrier constantly on its link and provides the carrier signal to the Ethernet chip. This only occurs when the ThinWire is not connected, NOT when there is ThinWire connected with no terminator on the ThinWire. Since Ethernet is CSMA-CD (Carrier Sense Multiple Access with Collision Detect) and since carrier is asserted constantly, the bridge cannot transmit on the link (the Ethernet chip will wait until carrier drops before attempting to transmit). Since the bridge cannot transmit, it will not record ten "loss of carrier" errors. In this case the "no frame interval" will expire and the link will be tested. When the ThickWire port is selected and no transceiver is connected, the carrier is not present (carrier is provided by the transceiver). Therefore the Ethernet chip will attempt to transmit, then notice that carrier is not present, and record a "loss of carrier". After ten transmissions, the link will be tested, the loopback test will fail, and the link will be transitioned to the "broken" state. John Poulin LANBU Engineering
406.2		KERNEL::WOODWARD	Smile!	`Thu Dec 05 1991 04:57`	3
	Thanks, that answers the question very nicely. Steve