Conference netcad::hub_mgnt

    If the previous codenol star was Passive, then you might be seeing a
    "benefit" of the old passive star technology....
    
    Passive stars are VERY SIMILAR to a peice of thickwire ethernet, if all
    of the fiber optic legs are the same length (+/- x%).  But, if the
    remote fiber runs to the passive have MAJOR differences in the length
    of fiber runs, then you will experience a game of favoritism played by
    the optics.   The nodes CLOSEST TO THE STAR have a higher amplitude of
    light than the nodes furthest from the star (db Loss).   And if the light
    from the closest nodes is significantly more, it will affect the
    collision detect method, affectively ignoring collisions with the
    "far-away" nodes, allowing the closer nodes to HOG THE MEDIA.  
    
    This will manifest itself in REALLY great response on the nodes nearest
    the star, and the far-off nodes getting many  "remote failure to defer", 
    and "initially deferred packet" and collision counters.  
    
    Installing a real "active star" network will cause much fairer network
    allocation across the network.  Taking away the "personal Ethernet"
    from the closer nodes in the computer room, and allowing the "waste 
    treatment plant users" to actually participate in the plant network.
    
    If you are actually experiencing a problem, look at the Ethernet
    countres on each affected node.  Look at Collision rate, look at Send
    and Receive Failures, and compare them to the number of blocks
    received.  These are the counters on a node near me that is not having
    a very good day:
    > ncp
    ncp>tell cboanc show know line count
    
    Known Line Volatile Counters as of Sat Mar 26 16:17:04 EST 1994
    
    Line  =  SVA-0
    
              29990  Seconds since last zeroed
             770515  Data blocks received
             770511  Multicast blocks received
                  3  Receive failure, including:
                           Block check error
                           Framing error
                           Frame too long
           83006510  Bytes received
           83006322  Multicast bytes received
                  0  Data overrun
               2554  Data blocks sent
                535  Blocks sent, multiple collisions
                290  Blocks sent, single collision
                284  Blocks sent, initially deferred
               2549  Multicast blocks transmitted
             128031  Bytes sent
             127864  Multicast bytes transmitted
                  2  Send failure, including:
                           Excessive collisions
                           Remote failure to defer
                  0  Collision detect check failure
                  0  Unrecognized frame destination
                  6  System buffer unavailable
                241  User buffer unavailable
    
    
    >  I would be very Wary of the the media near this node.  I add up all
    of the "collision and deferred packet counters" and get:
    535+290+284=1109 packets that couldn't be sent, cause the cable was
    busy.  He only sent 2554 packets (2549 were broadcasts) which means he
    is NOT REALLY doing anything on the network, and almost HALF his
    packets didn't get out.   This node is having hard time getting onto
    the wire.  Look at these counters on your network, and see how the nodes
    are actually failing, now that they are so slow.  You may find one node
    who is broken, or perhaps a port of your repeater, or the fiber itself
    might be bad.  Look at the counters on the repeater ports too. 
    
    Your twelve-port network does not seem all that uncommon.  I have many
    customers happily running similar configurations.  Something is
    probably broken, and can be found using the counters.
    
    JR
    

    
    Hello,
    
    Thanks for your answer, I am going to call the customer to have the
    counters(I was not on site when he makes tests) .
    The Ethernet segment from which the customer is making tests seems to
    be very busy (peak 70% Ethernet) but it was the same before with the
    passive star .
    The problem is about the decrepeater 90 FL ,because I can't see any 
    counters, this repeater does not support it . If you look with Hubwatch 
    you can see nothing. 
    One thing also which can degrade performance is that each optic port (like
    before on the passive star same config but connected on to the star) is 
    connected also to a bridge (no manageable old technology Retix bridge).
    We have seen on documentation that these bridges are forwarding 6000pps
    instead of 14000 pps for our bridges. 
    Do you think these bridges can degrade performance when connected to
    the decrepeater 90 FL instead of the passive star ?
     
    The new Decrepeater 900 FP (12 ports optic) seems to have per port
    statistics which with Hubwatch it seems that we can see bytes, frames, 
    errors and collisions. Is it true ?
    
    Thanks in advance for your  answer 
     
    Regards
      

    Yes, the DECrepeater 900 FL has all the counters you need.