Conference 7.286::fddi

793.0. "Cluster appears slower after move to FDDI" by CRONIC::ANTROBUS (And we thank you for your support.) Wed Nov 18 1992 13:49

    
    	Recently, we moved one of our MI clusters over to an FDDI
    	ring.  Each boot node (6540/6340) was fitted with a DEMFA
    	controller and attached to the ring.  All satellites on
    	the cluster were migrated to the ring via a connection
    	from a DECbridge 610.
    
    	In setting up the cluster to migrate to FDDI, we made a
    	decision to leave in the existing DEMNA on each boot node.
    	The DEMNA is terminated at the back of the system via a
    	loopback connector, and it is physically attached to one
    	of the "segments" behind the DECbridge 610 (same one as
    	the satellites).  In addition, LRPSIZE was increased
    	to 4474 on the boot nodes (per the recommendations in
    	VMS V5.4-3 release notes) to take advantage of larger
    	packet sizes.
    
    	Since moving to the FDDI ring, the customer has reported
    	that network performance (hosting from node-to-node,
    	creating DECwindows displays using DECnet transport, etc)
    	has gotten slower.  In investigating the problem, I started
    	looking at the NCP line counters being reported on the
    	DEMFA and have notice the following:
    
    	Line = MFA-0
    
            7452  Seconds since last zeroed
         1058122  Data blocks received
          621889  Multicast blocks received
               0  Receive failure
       218093459  Bytes received
        72214434  Multicast bytes received
               0  Data overrun
    	  449251  Data blocks sent
            4480  Multicast blocks sent
        77063501  Bytes sent
          687863  Multicast bytes sent
               0  Send failure
               0  Unrecognized frame destination
               0  System buffer unavailable
    	       0  User buffer unavailable
       611039507  MAC frame count
               0  MAC error count
               0  MAC lost count
               0  Ring initializations initiated
               0  Ring initializations received
               0  MAC error count
               0  MAC lost count
               0  Ring initializations initiated
               0  Ring initializations received
               0  Ring beacons initiated
               0  Duplicate address test failures
               0  Duplicate tokens detected
               0  Ring purge errors
               0  FCI strip errors
               0  Traces initiated
               0  Traces received
               0  Directed beacons received
               0  Elasticity buffer errors
               0  LCT rejects
               0  LEM rejects
               0  Link errors
               0  Connections completed
    
    	Notice, that the 'MAC frame count' counter grows quite large
    	in a short period of time.   Being new to this configuration,
    	I'm not clear as to what this counter is telling me.  Is
    	there any documentation available that describe these counters ?
    	Also, any other suggestions for troubleshooting the perceived
    	performance degradation.
    
    	thanks !
    	Deb

The FDDI architecture spec may help.

"Frame counter" is a useless counter mandated  by the FDDI standard.  It
counts every frame that passes by your station (whether addressed to you,
to someone else, or to no one at all).  In installations where the Ring Purger
is active -- which it is by default given that you have DEC products -- there
are lots of "void" frames.  Those are frames addressed to no one, copied by
no one, using no useful bandwidth.  The ring purger uses those frames to do
its job.  Unfortunately, the Frame Count includes void frames in its count,
which makes it even more useless than it otherwise would have been!

	paul

    re .0
    
    The same happens to me. During the FDDI configuration the whole cluster
    is getting slow somehow.
    
    In addition I've seen several '%PEA0, port has closed virtual circuit'
    at the console (6-10/hour). Did you notice this message ?
    This message is the only what I have to start work from.
    
    The workaround at the moment is to switch back to the Ethernet.
    The DEMFA is terminated.
    
    Have a look at #787.2
    

    
    Something to look for is duplicate LAN addresses enabled on both the
    Ethernet and FDDI adapters.  If this happens (which is allowed by a
    known bug which is in the DEMFA -- I think), your LAN performance is
    degraded.  Bridges rightfully get confused when a LAN address is
    reachable on both LANs it's connecting.
    
    How to detect this condition.
    
    There's probably an easier way, but I'll list the following;
    
    1) Go into SDA (type ANA/SYS).
    
    2) type 'show lan/dev=ex'
    
    3) Record both hardware address and physical address displayed.
    
    4) type 'show lan/dev=fc'
    
    5) Note the phys and hardware address displayed here.  If you have a
    match to the ex's address, STOP -- you've found your problem.
    
    6) If there isn't a match, continue typing the carriage return until
    you get to the 'Unit Information' screens.  Check the physical address
    displayed on all the Units enabled.  If you find a match to the ex's
    address, STOP -- you've found your problem.
    
    The most common cause of this is starting LAT on the 'non-DECnet'
    controller without specifying the /NODECNET switch.
    
    Kirt
    

    
    Change 'show lan/dev=fc' in my previous reply to
    
    		'show lan/dev=fx'
    
    Kirt
    

Just a side note, make sure any unused ports on the DECbridge 6xx are terminated
with a loopback connector