[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

589.0. "DB620 perf. Pb if NI not terminated" by SOS6::GROSSETETE () Wed May 27 1992 12:47

    	On a DECbridge 620 running firmware version 2.9.0,
    software version 1.1F, I noticed the performance's problem
    described below.
    
    	I used the following configuration to test the DECbridge 620
    forwarding rate
    
    		HP4972 LAN Analyzer # 1
    			!
    	------------------------------------ Ethernet LAN (DELNI)
    		!
    	DECbridge 520
    	!	    !
    	!	    !	FDDI Ring
    	!	    !
    	DECbridge 620
    		!
    	----------------------------------- Ethernet LAN (DELNI)
    			!
    		HP4972 LAN Analyzer # 2
    
    	HP4972 LAN Analyzer # 1 is transmitting packets (64bytes) to an unknown
    address (ie: 08-00-2B-09-09-09) with a valid protocol type (ie: 60-06)
    Traffic Generator option (STATS software) is used at 45% of load
    which is the maximum for 64 bytes packets in this HP4972 configuration.
    
    	HP4972 LAN Analyzer # 2 is just receiving packets, the load &
    total of received packets are displayed using STATS software.
    
    	Now, the problem description :
    
    If all unused Ethernet ports are terminated with loopback connectors,
    everything is working fine. All packets transmitted from HP # 1 are
    received on HP # 2. Yellow LED on all Ports is fixed ON.
    HP # 2 is showing permanently a 45 % traffic load.
    
    If any Ethernet port is not terminated by a Loopback connector,
    every 15 seconds, I can see :
    . all Yellow LEDs on Ethernet ports blinked (not the one on the FDDI port)
    . HP # 2 load % dropped from 45 % to about 30 %
    . Total of received frames is about 10000 packets less that the total
    of transmitted frames for 500000 packets.
     
    	I think this is caused by Ethernet ports polling to see if
    the carrier is there, but :
    .	Could somebody explain how Ethernet ports checking
    	is working ?
    
    .	Is it normal ? If yes, it must be documented
    	This will mean that a bad port/transceiver will cause a performance
    	drop on the DECbridge 620.
    
    As the same problem has been seen on 12 x DECbridge 620, I don't
    think it's a failure on my units.
    
    	Patrick
    
T.RTitleUserPersonal
Name
DateLines
589.1Known behaviorQUIVER::POULINWed May 27 1992 14:0334
    
    
    .0 is correct in that a periodic check of the port (every 15 seconds)
    occurs to determine if the port is "OK".  Actually, a loopback test is
    performed which would fail if the transceiver, AUI cable or coax is
    broken (or missing).  A detailed discussion of how this is done would
    involve proprietary information.
    
    See Note 482.*.
    
    This is being documented.
    
    Some comments concerning the performance data in .0:
    
    1.  The DECbridge does not forward all packets in all cases (the case
        in .0 is just one example).
    
    2.  The bridge is designed to operate at "well above" the performance
        requirements of "most" customers.
    
    3.  Design decisions were made that traded off performance for network
    	stability (something our competitors sometimes fail to do).
    
    4.  If a customer is experiencing performance problems that appear to
    	involve the DECbridge, there is a strong possibility that the
    	network segments attached to the bridge are operating at such a
    	high level of utilization that the segments themselves are unstable
    	or operating beyond recommended limits.
    
    
    John
    
    
    
589.2performance is neededABACUS::BUKOWSKIWed May 27 1992 16:3510
    re:-1
    
    	So what are the recommended segment utilization levels?  I have
        segments that typically run at 60% and spend a few hours at 80+%
    	and even peak in the high 80s that I need to convert over to bridge
    	610's.  Am I going to recieve timeouts on LAT protocol?  Will the
    	bridge drop packets?  Should I buy 3 bridge 510s for every bridge
    	610 that I plan on purchasing?
    
    	Mike
589.360% is high, 80% is overloadedLEVERS::S_JACOBSLive Free and ProsperWed May 27 1992 17:1018
    If you are seeing "utilization" in the 80% range, it is likely that a
    large portion of that utilization is collisions.  That segment should
    be divided up into smaller segments wherever traffic can be localized. 
    
    If the traffic cannot be localized, then an FDDI backbone with multiple
    DB620's serving segments with reasonable station counts should help the
    overall network throughput.  If it is a case of lots of clients ganging
    up on one server, look into putting the server directly on the FDDI
    ring.
    
    Using three DB520's instead of one DB620 will give you increased
    bandwidth between FDDI and Ethernet if the average packet sizes are
    small (less than 100 bytes) and the utilization of all three Ethernets 
    is in the 60% range.  Note however that Ethernet to Ethernet traffic 
    will then be going over the FDDI ring instead of being bridged directly 
    to the outbound port.
    
    Steve
589.4ABACUS::BUKOWSKIThu May 28 1992 13:0536
    RE:-1
    
    	In my network, we have both types of traffic situations that you
    had mentioned.  We do try to localize traffic where we are able to,
    but having approximately 3500 customers on one LAN constantly moving
    around doesn't make for a ideal network.   We have ordered 610's to
    be placed on our FDDI backbone which will replace all of our 10/10
    bridges.  It should work out fine, since most of the high utilization
    segments (50+%) are localized traffic (vary large MIVC's), and those
    bridges are filtering most of the traffic.
    
    	You mentioned that if many clients were using a server node, then
    the server node should be connected directly to the FDDI ring.  Well,
    that would force the DB610's to forward many more packets, and that
    is what these bridges can't do vary fast.  So did I mis-interpret
    something?
    
    	You also mentioned that the DB5xx's will provide increased
    performance between the Ethernet port and FDDI ring, but only if the
    packet sizes were less than 100 and utilization less than 60%.   Why 100
    and 60%?   Are you approximating or is there a guideline paper
    available?
    
    	One last topic.  You mentioned that Ethernet to Ethernet traffic
    will have to go over the FDDI ring instead of being bridged directly to
    the outbond port.  Does this mean that the DB6xx's bridge amongst the
    three Ethernet ports and then goes out over the FDDI port only if
    needed?   I thought that the DB6xx's were like having three bridge in
    one box and that the FDDI port was shared, and that all packets
    originating on Ethernet A and not destined for Ethernet A would be
    sent out Ethernet B, Ethernet C, and the FDDI port.  Am I incorrect?
    
    Mike
    
    
    	
589.5packets per second more importantQUIVER::POULINThu May 28 1992 13:5656
    
    
    Please do not assume that the DECbridges "can't forward packets very
    fast".  This is not true.  The DECbridges are very high performers.
    
    They do not perform, however, at the highest possible rate.  They do
    not need to.  They were designed to handle traffic more than
    adequately.
    
    Packet sizes are important for the following reasons:
    
    1.  The maximum packet per second rate for 1518 byte packets (the
    	largest possible on Ethernet) is about 780 pps.  The maximum pps
    	rate for 64 byte packets (the smallest possible on Ethernet) is
    	about 14,881 pps.
    
    2.  Generally speaking, the bridge performs the same amount of work on
    	a packet independent of packet size.
    
    3.  If the Ethernet segment has all 1518 bytes packets on it, it takes
    	only 780 pps to reach 100% utilization.  If the segment has all
    	minimum size packets it takes 14,881 pps to reach 100%.
    
    4.  When speaking about segment utilization, one must consider the
    	distribution of packet sizes in order to completely characterize the
    	"offered load" (the load presented to the bridge) because of (2)
    	(ie. 80% at 100 bytes per packet is very different than 80% at 1500
    	bytes per packet from a packets per second view).
    
    5.  Most packet size distributions fall within the range that the
    	bridge can process.
    
    
    Try repeating your experiment with packet sizes approximating the
    actual offered load (although this kind of work has already be done
    by the NaC Performance Evaluation Group).
    
    About the bridging of packets, the bridge will forward a packet to the
    port that the bridge learned the address on.  It does not forward the
    packet to all other ports.  In your experiment, the bridge did not get a
    chance to learn the destination port of the packet that you sent to the
    bridge because the bridge must "see" the address as a source address on
    a port in order to learn it.  In your case the address was always a
    destination, never a source.
    
    
    John
    
    
    
    
    
    
    
    
    
589.6more on DB6XX performanceLEVERS::S_JACOBSLive Free and ProsperThu May 28 1992 16:2555
Hi Mike:
    
    Here's some feedback on your questions:
    
        
>    	You mentioned that if many clients were using a server node, then
>    the server node should be connected directly to the FDDI ring.  Well,
>    that would force the DB610's to forward many more packets, and that
>    is what these bridges can't do vary fast.  So did I mis-interpret
>    something?
 
    When I said to put the server on FDDI, I had assumed that the clients
    were scattered over many separate Enet LAN segments.  If you have an
    Ethernet LAVC with a local server, then it makes sense to put the server 
    directly on the Ethernet.
       
>    	You also mentioned that the DB5xx's will provide increased
>    performance between the Ethernet port and FDDI ring, but only if the
>    packet sizes were less than 100 and utilization less than 60%.   Why 100
>    and 60%?   Are you approximating or is there a guideline paper
>    available?
    
    There is a "white paper" on this subject.  I don't have a soft copy. 
    If some other noter has one, maybe they can post it here.  I would hope
    that you could get one through Marketing, since that is the whole
    reason we wrote the darn thing.
    
    The translation performance is the same for the 5XX and 6XX bridges. 
    It works out to be slightly less than 20Kpps.  So you can see that with
    a single ethernet port the FDDI-ENET translation is full performance.
    
    With 3 ethernet ports, the 20Kpps is divided among the three ports.
    ONLY THE PACKETS THAT GO BETWEEN FDDI AND ETHERNET ARE TRANSLATED.  Any
    ethernet to ethernet traffic stays away from FDDI entirely.
    This leaves about 6.5Kpps of translation per port.  6.5Kpps is what you
    get when an Ethernet is 60% utilized with packets that have an average
    size of 100 bytes.
    
    
>    	One last topic.  You mentioned that Ethernet to Ethernet traffic
>    will have to go over the FDDI ring instead of being bridged directly to
>    the outbond port.  Does this mean that the DB6xx's bridge amongst the
>    three Ethernet ports and then goes out over the FDDI port only if
>    needed?   I thought that the DB6xx's were like having three bridge in
>    one box and that the FDDI port was shared, and that all packets
>    originating on Ethernet A and not destined for Ethernet A would be
>    sent out Ethernet B, Ethernet C, and the FDDI port.  Am I incorrect?
    
    As John mentioned, the DB6XX bridges are true multiport bridges.  They
    bridge from any port to any port without the packet showing up on any
    unnecessary port.  The DB6XX is not the same as three DB5XX in a box.
    You would only use multiple DB5XX in place of a single DB6XX if a
    customer ABSOLUTELY demanded full-performance.  There are studies and
    references in literature that specify 60% as a maximum practical load
    for ethernet.