Conference 7.286::ethernet

Twisted pair ethernet defines a collision as simultaneous transmission and
reception. So, you are correct in your assumption. (Please don't confuse
this with full duplex ethernet wherein collision detection is disabled and
allows simultaneous rx and tx.)

But I don't see why you say that you have an "inordinate" number of
collisions. If the node and the bridge were in lock-step, then you could
imagine a large burst of collisions like the ones shown. Lock-step often
occurs when there is a large amount of data that gets generated via a 
common event. Broadcast storms might qualify as such an event (although
briges are often used to filter them out).

In any case, I'm not the expert when it comes to analyzing real-world
traffic patterns. I'm sure some other reader can help you there.

regards,
bill

    Thank you. But I'm still having trouble with this. My thick 
    skull :-( understands sending at the same time and someone else
    sending also will cause a collision, if I haven't already aquired the
    wire. But it sounds like the node is sensing its own transmissions. At
    least that's what I alluded to, and looks like you confirmed. I'm 
    sorry, but sometimes I have to be hit in the head with a bat to have 
    things sink in. Still need an explaination of this phenomenon.
    
    On the number of collisions I'm seeing. I don't think I should see any
    since I'm on one port of a DECswitch 900EF and one other node is
    plugged into another port. Ie two different collision domains.
    
    Bob
      

    Bob, I of course am somewhat familiar with your lab setup and
    presume that your end nodes you are referring to are a pair of
    sister unix box's. Perhaps what is being seen is the NIC cards 
    sensing heartbeat from an attached transceiver, yet the software 
    driver doesn't know what to do with the reported heartbeat packets, 
    so it counts them as collisions. 
    Maybe by turning off heartbeat (SQE) at the transceivers being used, 
    the collisions being detected by the nodes will go away. Unless I didn't
    read your base note carefully, and you have the nodes directly connected
    to the DECswitch900EF, I can't think of a plausible reason for what's
    going on either.
    
    
    Bob

    Ok I went back and looked at the base note. If it was the
    heartbeat being detected as collisions, for every transmitted
    packet by the end nodes, there would be a collision being reported.
    Such is apparently not the case. The transmitted packets are in
    the 2000's and the number of collisions are 1/5th that rate.
    
    Bob

    Bob,
    
    The two nodes I'm talking about are CMTSRV and PANGEA. The twisted pair
    connections run from the UTP connection on the NIC card in the lab 
    straight to the comm closet into two ports on a WGE RTOS Bridge. The 
    bridge is connected via flex channels to other repeaters in the HUB. 
    An FDDI connection comes out of the front of the RTOS bridge to an FDDI
    concentrator on the second floor.
    
    Without getting into the nitty gritty of the spec. It appears that
    the DEC425 NIC can be transmitting a signal, and could simultaneously
    sense activity on the Recieve pair. This it detects as a collision.
    
    Hey maybe I just got it (after talking and thinking about it for the
    past couple of days)? If this is so, then that accounts for all the
    collisions I'm seeing on these two nodes. It would also account for
    some of the degradation in the performance on these two nodes, since 
    the node would have to back off and try each time it senses a
    collision.
    
    It's as clear as mud, but it covers the ground.
    
    Bob

 >   This node along with a sister node are both using twisted-pair.
 >   Both nodes terminate in a Bridge in a Hub. So I should not be 
 >   seeing any collisions.

Given what you said in .1 and .3, i don't understand your configuration. Of 
COURSE you can see collisions when you are connected to a bridge, 
especially if the distance between the node and the bridge is long (say, 
the 100m max cable length of 10BaseT). Remember, your link to the bridge is 
its own collision domain, which means there WILL BE COLLISIONS! It is true, 
though, that a collision on another port will not cause a collision on 
yours. But i don't see your data implying that.

It will help a lot if you drew a simple diagram showing your config 
(including cable lengths) and also info about what network processes are 
running on the Unix platform(s).

regards,
bill

      << .6
    
                                   ___
                                  |   |
       PANGEA .....UTP..............  | The UTP runs can't be more than
                                  |   | 60 feet, if that.
                                  |   |
       CMTSRV......UTP..............  |
                                  |   |
                                  |   |
                                  | F |
                                  | d |
                                  | d |
                                  | i |
                                  -----
    
    The twisted pair had gone into a Repeater prior to Friday. The 
    issue was performance, as a number of users access CMTSRV.
    Moving these two nodes over to a bridge did nothing for the 
    performance. But the collision rate did decrease somewhat.
    
    As mentioned in .5. I think I finally got it. It just seems 
    like a waste of time (Network performance wise) to be acting 
    this way.
    
       

>    As mentioned in .5. I think I finally got it. It just seems 
>    like a waste of time (Network performance wise) to be acting 
>    this way.

I agree. In fact, that's one of the reasons why full duplex ethernet was 
invented! If you and the node you are talking to constitutes the entire 
"collision domain" then there's no reason for collisions. Collisions 
exist to help abitrate shared media. But since the data path is 
point-to-point, there IS no shared media.

If the bridge and the NIC support full dup ethernet, you should set them up 
to do so. You might be happier with the performance since you could get up 
to 20 mbit/s (TX and RX simultaneously).

Hope this helps,
bill

    Bill, thanks for you help. I don't think the Decswitch900ef 
    or the DEC425 card supports full dux, but it won't hurt to check.
    
    Bob
    

The DE425 does support Full Duplex (though support of it depends on what O/S
you are running).

    And the DECswitch 900EF doesn't support full duplex on its
    utp ports. So the problem may be that the DE425 is defaulting
    to full duplex eh?
    
    Bob

    re .10 
    
    Digital UNIX V3.2C  (Rev. 148); Sat Dec 21 08:18:22 EST 1996
    Digital UNIX V3.2C Worksystem Software (Rev. 148)
    
    And I'm assuming a DEC425 because of the tu0 interface. 
    
    If the device is running full dux how can I tell it, and how can
    I change it?
    
    re .11
    
    Right Bob, I found that the DECswitch 900ef does not support full dux
    after I entered .9
    
    Bob
    
    
    

ifconfig tu0 speed 10   will force it to half duplex.

You might look at the console setting for the card to see what the
console thinks it should be.

    Unfortunately this ifconfig command does not work. Speed appears 
    to be related to token-ring. Thanks for the input anywho. I don't
    have root privs so I'm not able to check things out like I would.
    Will pass this on to the system manager.
    
    Bob