[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

3372.0. "Possible problem after 4.1.1, etc F/W upgrade" by GIDDAY::STANISLAUS () Mon Mar 18 1996 17:32

    
    
    
    	The following happened after a DEChub 900/DH90 modules F/W upgrade.
    	------------------------------------------------------------------
    
    	Upgraded modules. There is only one DH900 and 16 DH90 units. 
    
    	MAM to 4.1.1
    	1 x DC900MX to 3.1.1 
    	1 x DS900EF to 1.5.2
    	3 x DR90TS in the DH900 and dozens of DR90TS in all DH90 units to
   	2.0
        DR900 FP was left at version 1.1, becuase of a known problem in
    	version 2.0 when Thinwire is not connected.
    
    		  		
    	The diagram for this site is in this conference note number 3355.
    
    	The problem on this site is one of INTERMITTENT poor response
    	about 300 PC clients running Pathworks and 3 Pathworks AXP servers
    	using Netbeui Transport as explained in this conference note number
    	3351 on DEFEA FDDI controller.
    
    	An IRIS trace when response is poor shows the communication between
    	Server and PC (NEtbeui is the Pathworks Transport) works with a
    	Window size of 1. When response is good an IRIS trace shows the
    	server sends many packets (8 to 10) before waiting for an ACK from
    	the PC. Once the server starts communicating with a window size of
    	1, it stays in that mode up until Pathworks is shutdown and
    	restarted on the server.
    
    	On checking FDDI and Ethernet counters of the various modules and
    	servers there are some (but very very few - about half-a-dozen) CRC
    	errors and RING INITS received PER DAY. I didn't think that should
    	slow Pathworks users permanently until Pathworks shutdown/restart.
    
    	Customer INSISTED that the problem started after F/W upgrade. He 
    	has been running reasonably well for 4 months before F/W upgrade.
    	Another thing that happened after F/W upgrade was he lost the
    	IMB configs and we configured it as the way shown in note 3355 of 
    	this conference which other people have said looks OK. Customer did
    	not have diagram of IMB configs before F/W upgrade. Anyway under 
    	customer pressure we downgraded the F/W to the following (don't
    	know what he had originally):
    
    	MAM to 4.0.2
    	DC900MX to 3.0.1
    	DS900EF to 1.5.0
    	DR90TS all of them to 1.1
    
    	He has now run for 24 hours with any problem. Although it is too
    	early to say customer believes it is now fixed.
    
    	Has anyone seen this kind of problem of problem after F/W upgrade.
    	Customer uses the Hubs for Pathworks and Appletalk connectivity.
    	While Pathworks users slowed down Apple users were working happily.
        Cluster traffic between servers, LAT and DECnet users (not too many
    	of them anyway) do not get affected.
    
    	My theory (may be wrong): May be just one RING INIT or one Ethernet
    	error say causes one packet loss from server to PC. May be the
    	packet loss causes Netbeui transport (used by Pathworks) to go into
    	transmitting with a Window size of 1. May be there is a bug in
    	Pathworks using Netbeui which causes the server to stay in this	
    	mode until Pathworks is shutdown/restarted.
    
    	Pathworks on the server is version 5.0 with ECO 3.
    
    	VMS is ver 6.2
    
    	UCX is version 3.2 with ECO Level 6. UCX is only used by some PCs
    	for ftp and telnet.
    
    
    	Alphonse
    	
T.RTitleUserPersonal
Name
DateLines