Conference 7.286::fddi

    
    Jan,
    
    Bytes sent does not equal bytes received when considering the counters
    in the DECbridge 620 (or any DECbridge).
    
    Bytes sent are those in packets that the bridge originates itself
    (management, spanning tree) on the FDDI plus the forwarded traffic to
    FDDI (from Ethernet ports).  Bytes received would be ALL bytes received
    by the bridge from the FDDI (including packets filtered, forwarded, or
    destined to the bridge (management, spanning tree)).
    
    However, currently, the DECbridges do not support a bytes received
    counter on the FDDI port (and hence utilization statistics are not
    supported either).
    
    John
    
    
    
    
    

    John,
    
    Thanks a lot for your quick reply ! This clarifies alot and makes it
    less foggy for me.
    
    Cheers,
    Jan

My customer is interested in having network utilisation statistics, also for FDDI.
Now what's the  reason why DECbridges don't implement this counter ?
I think on some FDDI controllers this counter is available, but what exactly does 
it represent ?. Does a total bytes received counter also contain the bytes that 
are just passed downstream by the DECbridge ?


	Guido

    
    Guido,
    
    The "passing downstream" of packets occurs on a token ring regardless
    of whether the packet is actually received or not (it's up to each
    transmitting station to "remove" its own packets from the ring in all
    cases).
    
    Since the bridge is in promiscuous receive mode on the FDDI, it
    actually receives ALL packets on the FDDI, therefore a received bytes
    counter, IF there was one, would indicate all bytes on the FDDI.  It
    makes the decision to forward or filter the packet AFTER the packet has
    been received fully.
    
    The DECbridge hardware does not include such a counter on the FDDI.
    Nor does any FDDI adapter from DEC.  It's simply not in the hardware.
    
    John
    
    
    
    

    re: -1
    
    You mention that bytes received on the FDDI port is everything that
    passes on the ring.   We'll isn't the bytes received counter on a 
    802.3 line of a bridge considered to be the total of the all bytes
    on that Ethernet segment.  So, the FDDI controllers aught to count
    all bytes recieved as well.  At least we would have some way of 
    calculating utilization.  Or are we and our customers going to be 
    forced into buying separate hardware for FDDI statistics?  Our group
    can not afford to be running 20 + Bridge 610 without having FDDI
    statistics, so we will be looking into 3 party FDDI analyzers.  Any
    suggestions or preferences on vendors?
    
    Mike
    

Time to clarify the definitions.

"Bytes received" -- or for that matter "xxx received" for any xxx -- the
term "received" refers to frames that match the receive criteria for this
station.  It does NOT refer to chatter on the wire that the station doesn't
care about.  

For an "ordinary" station, received frames are those that have the right
destination address -- matching the station address, or an enabled multicast
address.  For a station in promiscuous mode, the address doesn't matter
and therefore pretty much everything on the wire is "received".

A more precise definition can be found in the FDDI data link architecture.

As for other station types: .4 is correct in that the hardware doesn't have
a byte counter.  However, support for the byte counters is provided by the
driver software for the adapters, so as far as a user can tell, you DO get
support for byte counters with the adapters.  But note, as described above,
that this only gives you statistics for traffic actually being received by
the node, not usage information about traffic for other nodes.

	paul

    re: .6
    
    Ok.  I overlooked the fact that stations on the ring do not always see
    the data passed between two other stations on the ring, but the data
    that is destined for a bridge should be accounted for by the driver
    software.
    
    Do you know where I could get a copy of the FDDI data link
    architecture?
    
    Thanks,
    Mike
       

    
    Mike,
    
    The bridge does not contain "driver" software in the usual sense.
    Drivers are usually associated with operating systems on host
    endstations.  The bridge is an imbedded system.
    
    Without getting into specifics (proprietary information), a design
    decision was made to not support a byte counter due to that fact that
    an inter-arrival time of 2.48 uSec per packet (min size) did not leave
    enough time left over to process a counter.  Byte counters require services
    such as determining the size of the packet and handling wrapping.
    Providing a byte counter would have adversely impacted high end
    performance.
    
    Please realize that the following is just my opinion, since I am not a
    network manager; with a large number of bridges and/or stations on
    any network, a LANanalyzer is required for managing the network.  
    Determining utilization statistics is just one of many data points
    (packet size, protocol, and burst characteristics are just a few that
    come to mind).  Obtaining network statistics from bridges should not be
    regarded as the primary means of network analysis.  We as designers
    attempt to make our products as useful as possible but, remember the
    main purpose of the bridge is to connect FDDI to Ethernet.
    
    John
    
    
    
    

Actually, checking for wrapping can be done in the background, but even so
the argument for not doing it in the bridge is sensible.

	paul

    
    Paul,
    
    Checking wrapping cannot be done in the background if there is no
    background time left over.  This is the case according to the
    particular engineer that was assigned to the development of that
    piece of the bridge.
    
    If it could have been done, it would have been done.
    
    John (who absolutely MUST have the last word :-)