How exactly does an Ethernet collision happen in the cable, since nodes use different circuits for Tx and Rx?












7















I am trying to understand how a collision occurs in Ethernet, especially when a duplex mismatch exists or when on a legacy Ethernet network two nodes transmit simultaneously.



Everyone explains the collision in an upper level (two frames collide when the one is being sent and the other is being received). However, the graph below shows that there are different circuits for Rx and Tx. How a collision can happen since there are dedicated circuits for sending and receiving frames?



Different circuits are used for transmission and receipt



EDIT: Maybe the label "Hub MDI-X" causes some confusion regarding the point of my question. I am not asking how the functionallity of a hub can cause collision. My focus is on the communicaton between two nodes with either MDI or MDI-X interfaces (hub and switches have MDI-X interfaces). In any of these two cases, how a collision can happen between two nodes when they have duplex mismatch, whilst in duplex mismatch Rx and Tx have still their dedicated circuits?










share|improve this question









New contributor




Christos Dalamagkas is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





















  • Please note that 10Base2 or 10Base5 shared the same medium, e.g. the same cable.

    – Patrick Terlisten
    14 hours ago











  • Still I have the same question regarding 100base-tx, in case we have duplex mismatch and the nodeA is half duplex and nodeB full duplex. Suppose nodeA has an MDI interface and nodeB an MDI-X one. NodeB transmits from pins 3 and 4 and nodeB only receives from 3 and 4. How a collision can happen in nodeA since it only receives from these pins?

    – Christos Dalamagkas
    13 hours ago






  • 4





    The collision happens in L1, not L2 - it's the bits/carriers that collide. Two senders collide when they try to send (near) simultaneously.

    – Zac67
    10 hours ago
















7















I am trying to understand how a collision occurs in Ethernet, especially when a duplex mismatch exists or when on a legacy Ethernet network two nodes transmit simultaneously.



Everyone explains the collision in an upper level (two frames collide when the one is being sent and the other is being received). However, the graph below shows that there are different circuits for Rx and Tx. How a collision can happen since there are dedicated circuits for sending and receiving frames?



Different circuits are used for transmission and receipt



EDIT: Maybe the label "Hub MDI-X" causes some confusion regarding the point of my question. I am not asking how the functionallity of a hub can cause collision. My focus is on the communicaton between two nodes with either MDI or MDI-X interfaces (hub and switches have MDI-X interfaces). In any of these two cases, how a collision can happen between two nodes when they have duplex mismatch, whilst in duplex mismatch Rx and Tx have still their dedicated circuits?










share|improve this question









New contributor




Christos Dalamagkas is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





















  • Please note that 10Base2 or 10Base5 shared the same medium, e.g. the same cable.

    – Patrick Terlisten
    14 hours ago











  • Still I have the same question regarding 100base-tx, in case we have duplex mismatch and the nodeA is half duplex and nodeB full duplex. Suppose nodeA has an MDI interface and nodeB an MDI-X one. NodeB transmits from pins 3 and 4 and nodeB only receives from 3 and 4. How a collision can happen in nodeA since it only receives from these pins?

    – Christos Dalamagkas
    13 hours ago






  • 4





    The collision happens in L1, not L2 - it's the bits/carriers that collide. Two senders collide when they try to send (near) simultaneously.

    – Zac67
    10 hours ago














7












7








7


2






I am trying to understand how a collision occurs in Ethernet, especially when a duplex mismatch exists or when on a legacy Ethernet network two nodes transmit simultaneously.



Everyone explains the collision in an upper level (two frames collide when the one is being sent and the other is being received). However, the graph below shows that there are different circuits for Rx and Tx. How a collision can happen since there are dedicated circuits for sending and receiving frames?



Different circuits are used for transmission and receipt



EDIT: Maybe the label "Hub MDI-X" causes some confusion regarding the point of my question. I am not asking how the functionallity of a hub can cause collision. My focus is on the communicaton between two nodes with either MDI or MDI-X interfaces (hub and switches have MDI-X interfaces). In any of these two cases, how a collision can happen between two nodes when they have duplex mismatch, whilst in duplex mismatch Rx and Tx have still their dedicated circuits?










share|improve this question









New contributor




Christos Dalamagkas is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.












I am trying to understand how a collision occurs in Ethernet, especially when a duplex mismatch exists or when on a legacy Ethernet network two nodes transmit simultaneously.



Everyone explains the collision in an upper level (two frames collide when the one is being sent and the other is being received). However, the graph below shows that there are different circuits for Rx and Tx. How a collision can happen since there are dedicated circuits for sending and receiving frames?



Different circuits are used for transmission and receipt



EDIT: Maybe the label "Hub MDI-X" causes some confusion regarding the point of my question. I am not asking how the functionallity of a hub can cause collision. My focus is on the communicaton between two nodes with either MDI or MDI-X interfaces (hub and switches have MDI-X interfaces). In any of these two cases, how a collision can happen between two nodes when they have duplex mismatch, whilst in duplex mismatch Rx and Tx have still their dedicated circuits?







ethernet layer1 utp autonegotiation ieee-802.3x






share|improve this question









New contributor




Christos Dalamagkas is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question









New contributor




Christos Dalamagkas is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question








edited 9 hours ago







Christos Dalamagkas













New contributor




Christos Dalamagkas is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked 14 hours ago









Christos DalamagkasChristos Dalamagkas

363




363




New contributor




Christos Dalamagkas is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





Christos Dalamagkas is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






Christos Dalamagkas is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.













  • Please note that 10Base2 or 10Base5 shared the same medium, e.g. the same cable.

    – Patrick Terlisten
    14 hours ago











  • Still I have the same question regarding 100base-tx, in case we have duplex mismatch and the nodeA is half duplex and nodeB full duplex. Suppose nodeA has an MDI interface and nodeB an MDI-X one. NodeB transmits from pins 3 and 4 and nodeB only receives from 3 and 4. How a collision can happen in nodeA since it only receives from these pins?

    – Christos Dalamagkas
    13 hours ago






  • 4





    The collision happens in L1, not L2 - it's the bits/carriers that collide. Two senders collide when they try to send (near) simultaneously.

    – Zac67
    10 hours ago



















  • Please note that 10Base2 or 10Base5 shared the same medium, e.g. the same cable.

    – Patrick Terlisten
    14 hours ago











  • Still I have the same question regarding 100base-tx, in case we have duplex mismatch and the nodeA is half duplex and nodeB full duplex. Suppose nodeA has an MDI interface and nodeB an MDI-X one. NodeB transmits from pins 3 and 4 and nodeB only receives from 3 and 4. How a collision can happen in nodeA since it only receives from these pins?

    – Christos Dalamagkas
    13 hours ago






  • 4





    The collision happens in L1, not L2 - it's the bits/carriers that collide. Two senders collide when they try to send (near) simultaneously.

    – Zac67
    10 hours ago

















Please note that 10Base2 or 10Base5 shared the same medium, e.g. the same cable.

– Patrick Terlisten
14 hours ago





Please note that 10Base2 or 10Base5 shared the same medium, e.g. the same cable.

– Patrick Terlisten
14 hours ago













Still I have the same question regarding 100base-tx, in case we have duplex mismatch and the nodeA is half duplex and nodeB full duplex. Suppose nodeA has an MDI interface and nodeB an MDI-X one. NodeB transmits from pins 3 and 4 and nodeB only receives from 3 and 4. How a collision can happen in nodeA since it only receives from these pins?

– Christos Dalamagkas
13 hours ago





Still I have the same question regarding 100base-tx, in case we have duplex mismatch and the nodeA is half duplex and nodeB full duplex. Suppose nodeA has an MDI interface and nodeB an MDI-X one. NodeB transmits from pins 3 and 4 and nodeB only receives from 3 and 4. How a collision can happen in nodeA since it only receives from these pins?

– Christos Dalamagkas
13 hours ago




4




4





The collision happens in L1, not L2 - it's the bits/carriers that collide. Two senders collide when they try to send (near) simultaneously.

– Zac67
10 hours ago





The collision happens in L1, not L2 - it's the bits/carriers that collide. Two senders collide when they try to send (near) simultaneously.

– Zac67
10 hours ago










5 Answers
5






active

oldest

votes


















7














A hub is really just a powered cable that repeats every signal it receives on one interface to all the other interfaces. If two devices transmit at the same time to the receive of the hub interfaces, the hub repeats both signals at the same time to the transmit of all the other hub interfaces, and both signals received will collide at the transmit of the other interfaces, thus you have a collision where all the other interfaces have garbage signals because it is two signals at the same time. The hosts that are sending simultaneously and hear another signal will realize that more than one is is sending at a time, and they will determine that there is a collision.



Think of it this way, the receive of every hub interface is wired to the transmit of every other interface. Inside the hub, the transmit and receive are connected, even if they are separate at the interface.



Contrast that with a switch, where each link is terminated at the switch interface, and the switch does not have the interfaces wired together. Instead the switch has logic (usually embedded in hardware) to determine where to send frames it receives on one interface, and to prevent collisions inside the switch.



A switch is a high-density bridge. The original bridges were like PCs with multiple interfaces. You would not expect a PC with multiple interfaces to have collisions if it received simultaneous frames on multiple interfaces.





Edit:



Your comments lead me to believe you still do not understand what I wrote above about hubs.



The way collisions are detected when using UTP and a hub is by the sending devices hearing another signal while sending. If a device using UTP is configured for half duplex, then it will believe there is a collision when it hears a signal while sending.



When you have a duplex mismatch, the device configured for full duplex will happily send while receiving from the device configured for half duplex. On the other hand, the device configured for half duplex will believe that there is a collision when it is sending and hears that signal from the device configured for full duplex. That will cause all type of problems because the device configured for half duplex will stop sending the frame (causing a runt), and it will send a jamming signal that the device configured for full duplex is not expecting. The device configured for full duplex will then stop sending its frame.






share|improve this answer





















  • 2





    This is the real answer. OP is ignoring all cases except just two endpoints with a crossover cable (or, in a modern setting, any cable) between them.

    – R..
    10 hours ago











  • @R.., the drawing in the question shows a hub, so I answered for a hub connection.

    – Ron Maupin
    9 hours ago











  • This answer explains how the collision occurs when you have a Hub in the topology. Although a late collision can happen when there are two nodes (let's say a switch and a PC), the one is half-duplex and the other is full-duplex. Why a collision does happen in this case, even though there are separate circuits for Tx and Rx, as shown in the graph of my question?

    – Christos Dalamagkas
    9 hours ago











  • Seems that the label "Hub MDI-X" caused some confusion, regarding the point of my question. I edited accordingly.

    – Christos Dalamagkas
    9 hours ago






  • 2





    Because the one with half duplex declares a collision when it hears something while sending. See the answer above.. If a device configured for half-duplex hears another signal while sending, it must assume that there is a collision because it believes that it is half duplex and only one device at a time can send.

    – Ron Maupin
    9 hours ago



















5














Great question.



In full duplex, there is a dedicated channel for traffic from "left to right" and a dedicated channel from traffic from "right to left":



Dedicated Channel



Therefore, in full duplex, collisions are impossible -- even if both NIC's transmit at the same time.



In half-duplex, however, traffic in either direction is meant to only use the wire, one direction at a time. So while physically, there is still dedicated channels, logically if one NIC receives something while it is transmitting, it logs it as a collision. The bits/signal do not actually "collide" on the wire -- a collision counter is simply incremented when the NIC is Receiving and Transmitting at the same time.






share|improve this answer



















  • 3





    The signals do collide on the wire, even with twisted pair. With three end nodes, two simultaneous signals would collide on the third node.

    – Zac67
    9 hours ago






  • 2





    "The bits/signal do not actually "collide" on the wire" In a hub, as in the drawing in the question, the bits actually do collide on the wire and produce a garbage signal. The hosts that are sending simultaneously and hear another signal will then send a jamming signal to all the other interfaces on the hub.

    – Ron Maupin
    9 hours ago











  • @RonMaupin You're correct of course - I was referring to what would happen when the repeater wouldn't detect/react to the collision.

    – Zac67
    8 hours ago






  • 1





    @Zac67, I wasn't commenting for you, You and I said the same thing at basically the same time.

    – Ron Maupin
    8 hours ago











  • @Zac67 / RonMaupin The OP edited the question confirming they aren't asking about the case of hubs.

    – Eddie
    3 hours ago



















3














With twisted pair and a repeater hub, the hub is not much more than a digital amplifier. For that it senses a carrier from an incoming signal on one port and switches all other ports to output mode. In this output mode, any additional incoming carrier is a collision. This triggers a jam signal to propagate the collision and make the sender stop transmitting.



This repeating method mimicks the behavior of the previous, shared media Ethernet variants (10BASE5 & 10BASE2) where repeater were only used as physical segment joints or line extenders. Of course you're correct: twisted pair is a full duplex medium on the wire level where a collision only happens on the upper physical layer and not on the wire itself.



A repeater cannot permit more than one sender at the same time. Multiple simultaneous transmissions would mix on the output ports and produce unintelligible noise.



With a duplex mismatch, one link end is in half-duplex and the other in full-duplex mode. Now, when the half-duplex (HDX) side is transmitting, any carrier on its receiver causes a collision to be detected. However, the full-duplex (FDX) side may be happily sending away while it is receiving from the HDX side and it is completely oblivious to the collisions that creates on the far side. The HDX side needs to abort the transmission and sends a jam signal. Since the FDX side cannot detect the alleged collision it detects a partial and therefore damaged frame.



Low-frequency and small frames have a reasonable chance to get through this duplex mismatch, so a ping could actually work. However, as soon as any serious transmission is trying to get under way, the higher frame frequency and larger size will make the link fail very reliably.



With unmanaged switches, a duplex mismatch can be very hard to detect, especially when not even the host NICs report their duplex mode properly.



With managed switches, you usually have port error counters. Increasing collisions on one side and increasing runts and FCS errors on the other side are very strong indications for a duplex mismatch.



Basically, relying on Auto Negotiation is a very good practice to avoid duplex mismatches. Manually configuring speed and duplex mode is generally prone to creating a mismatch, especially when replacing equipment a few years later. Fortunately the whole half-duplex scheme went away with Gigabit Ethernet and faster.






share|improve this answer































    1














    Suppose machine A starts sending data to machine B. As the packet begins to be sent, machine C starts sending different data to machine B. There is only one signal path to machine B, so the transmissions from A and C collide and B cannot possibly receive both of them.



    The fact that a different circuit is used for transmissions from machine B, to machine A, and to machine C doesn't help. All that's happening is that A and C are trying to transmit to machine B at the same time and there is only one signal path to machine B.






    share|improve this answer































      0














      To understand this you need to understand the historical context.



      Originally Ethernet used a shared coaxial cable. Only one device could successfully transmit on this at a time. If two devices transmitted at the same time it was considered a collision.



      Then repeaters came along, to extend the distance and increase the number of nodes. A repeater would detect which port is transmitting, then it would repeat that signal out on the other ports. To keep the collision detection working repeaters had to have some functionality for ensuring that all nodes detected a collision. The first repeaters only had two ports, but later repeaters could have multiple ports and these became known as hubs, especially when used in conjunction with twisted-pair wiring. Repeaters were pretty dumb devices, they would regenerate the electrical signals,



      Then 10BASE-T came in, which as you have noticed has dedicated data channels for each direction. Nevertheless it still needed to fit into the existing model, so by default it operated in a "half-duplex" mode where it emulated a coaxial cable. The signals did not in-fact collide on the wire but the transceivers acted as-if they did and the repeaters would take the same steps as before to ensure this was seen across the network.



      Twisted pair Ethernet can also support a "full-duplex" mode. In this mode all of the collision-related hardware is disabled and both ends can transmit at any time. However this mode brought a couple of major downsides.




      • It was incompatible with repeater-hubs. Without the collision detection mechanisms hubs would have no way of handling two devices transmitting at the same time.

      • Both ends of a link to be set-up for the same duplex mode, if they are not then bad things will happen.


      These issues meant that in practice 10BASE-T systems nearly always operated in half-duplex mode.



      For 100BASE-TX the situation improved dramatically. Ethernet switches (technically fast multi-port bridges) came down in price to the point that dumb repeater hubs could be eliminated. Auto-negotiation allowed network cards to establish full-duplex connections without error-prone manual configuration. If you connect two 100BASE-TX NICs together with a crossover cable or connect a 100BASE-TX NIC to a switch and don't take steps to manually override things they will almost certainly negotiate full-duplex mode.



      1000BASE-T theoretically has a half-duplex mode which some NICs claim to support and there was a specification for gigabit multiport repeaters, but I have never seen any evidence that anyone ever sold one. In practice a gigabit link will almost-certainly be running in full-duplex mode.



      Faster speeds abandoned the half-duplex mode entirely.






      share|improve this answer























        Your Answer








        StackExchange.ready(function() {
        var channelOptions = {
        tags: "".split(" "),
        id: "496"
        };
        initTagRenderer("".split(" "), "".split(" "), channelOptions);

        StackExchange.using("externalEditor", function() {
        // Have to fire editor after snippets, if snippets enabled
        if (StackExchange.settings.snippets.snippetsEnabled) {
        StackExchange.using("snippets", function() {
        createEditor();
        });
        }
        else {
        createEditor();
        }
        });

        function createEditor() {
        StackExchange.prepareEditor({
        heartbeatType: 'answer',
        autoActivateHeartbeat: false,
        convertImagesToLinks: false,
        noModals: true,
        showLowRepImageUploadWarning: true,
        reputationToPostImages: null,
        bindNavPrevention: true,
        postfix: "",
        imageUploader: {
        brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
        contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
        allowUrls: true
        },
        noCode: true, onDemand: true,
        discardSelector: ".discard-answer"
        ,immediatelyShowMarkdownHelp:true
        });


        }
        });






        Christos Dalamagkas is a new contributor. Be nice, and check out our Code of Conduct.










        draft saved

        draft discarded


















        StackExchange.ready(
        function () {
        StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fnetworkengineering.stackexchange.com%2fquestions%2f57521%2fhow-exactly-does-an-ethernet-collision-happen-in-the-cable-since-nodes-use-diff%23new-answer', 'question_page');
        }
        );

        Post as a guest















        Required, but never shown

























        5 Answers
        5






        active

        oldest

        votes








        5 Answers
        5






        active

        oldest

        votes









        active

        oldest

        votes






        active

        oldest

        votes









        7














        A hub is really just a powered cable that repeats every signal it receives on one interface to all the other interfaces. If two devices transmit at the same time to the receive of the hub interfaces, the hub repeats both signals at the same time to the transmit of all the other hub interfaces, and both signals received will collide at the transmit of the other interfaces, thus you have a collision where all the other interfaces have garbage signals because it is two signals at the same time. The hosts that are sending simultaneously and hear another signal will realize that more than one is is sending at a time, and they will determine that there is a collision.



        Think of it this way, the receive of every hub interface is wired to the transmit of every other interface. Inside the hub, the transmit and receive are connected, even if they are separate at the interface.



        Contrast that with a switch, where each link is terminated at the switch interface, and the switch does not have the interfaces wired together. Instead the switch has logic (usually embedded in hardware) to determine where to send frames it receives on one interface, and to prevent collisions inside the switch.



        A switch is a high-density bridge. The original bridges were like PCs with multiple interfaces. You would not expect a PC with multiple interfaces to have collisions if it received simultaneous frames on multiple interfaces.





        Edit:



        Your comments lead me to believe you still do not understand what I wrote above about hubs.



        The way collisions are detected when using UTP and a hub is by the sending devices hearing another signal while sending. If a device using UTP is configured for half duplex, then it will believe there is a collision when it hears a signal while sending.



        When you have a duplex mismatch, the device configured for full duplex will happily send while receiving from the device configured for half duplex. On the other hand, the device configured for half duplex will believe that there is a collision when it is sending and hears that signal from the device configured for full duplex. That will cause all type of problems because the device configured for half duplex will stop sending the frame (causing a runt), and it will send a jamming signal that the device configured for full duplex is not expecting. The device configured for full duplex will then stop sending its frame.






        share|improve this answer





















        • 2





          This is the real answer. OP is ignoring all cases except just two endpoints with a crossover cable (or, in a modern setting, any cable) between them.

          – R..
          10 hours ago











        • @R.., the drawing in the question shows a hub, so I answered for a hub connection.

          – Ron Maupin
          9 hours ago











        • This answer explains how the collision occurs when you have a Hub in the topology. Although a late collision can happen when there are two nodes (let's say a switch and a PC), the one is half-duplex and the other is full-duplex. Why a collision does happen in this case, even though there are separate circuits for Tx and Rx, as shown in the graph of my question?

          – Christos Dalamagkas
          9 hours ago











        • Seems that the label "Hub MDI-X" caused some confusion, regarding the point of my question. I edited accordingly.

          – Christos Dalamagkas
          9 hours ago






        • 2





          Because the one with half duplex declares a collision when it hears something while sending. See the answer above.. If a device configured for half-duplex hears another signal while sending, it must assume that there is a collision because it believes that it is half duplex and only one device at a time can send.

          – Ron Maupin
          9 hours ago
















        7














        A hub is really just a powered cable that repeats every signal it receives on one interface to all the other interfaces. If two devices transmit at the same time to the receive of the hub interfaces, the hub repeats both signals at the same time to the transmit of all the other hub interfaces, and both signals received will collide at the transmit of the other interfaces, thus you have a collision where all the other interfaces have garbage signals because it is two signals at the same time. The hosts that are sending simultaneously and hear another signal will realize that more than one is is sending at a time, and they will determine that there is a collision.



        Think of it this way, the receive of every hub interface is wired to the transmit of every other interface. Inside the hub, the transmit and receive are connected, even if they are separate at the interface.



        Contrast that with a switch, where each link is terminated at the switch interface, and the switch does not have the interfaces wired together. Instead the switch has logic (usually embedded in hardware) to determine where to send frames it receives on one interface, and to prevent collisions inside the switch.



        A switch is a high-density bridge. The original bridges were like PCs with multiple interfaces. You would not expect a PC with multiple interfaces to have collisions if it received simultaneous frames on multiple interfaces.





        Edit:



        Your comments lead me to believe you still do not understand what I wrote above about hubs.



        The way collisions are detected when using UTP and a hub is by the sending devices hearing another signal while sending. If a device using UTP is configured for half duplex, then it will believe there is a collision when it hears a signal while sending.



        When you have a duplex mismatch, the device configured for full duplex will happily send while receiving from the device configured for half duplex. On the other hand, the device configured for half duplex will believe that there is a collision when it is sending and hears that signal from the device configured for full duplex. That will cause all type of problems because the device configured for half duplex will stop sending the frame (causing a runt), and it will send a jamming signal that the device configured for full duplex is not expecting. The device configured for full duplex will then stop sending its frame.






        share|improve this answer





















        • 2





          This is the real answer. OP is ignoring all cases except just two endpoints with a crossover cable (or, in a modern setting, any cable) between them.

          – R..
          10 hours ago











        • @R.., the drawing in the question shows a hub, so I answered for a hub connection.

          – Ron Maupin
          9 hours ago











        • This answer explains how the collision occurs when you have a Hub in the topology. Although a late collision can happen when there are two nodes (let's say a switch and a PC), the one is half-duplex and the other is full-duplex. Why a collision does happen in this case, even though there are separate circuits for Tx and Rx, as shown in the graph of my question?

          – Christos Dalamagkas
          9 hours ago











        • Seems that the label "Hub MDI-X" caused some confusion, regarding the point of my question. I edited accordingly.

          – Christos Dalamagkas
          9 hours ago






        • 2





          Because the one with half duplex declares a collision when it hears something while sending. See the answer above.. If a device configured for half-duplex hears another signal while sending, it must assume that there is a collision because it believes that it is half duplex and only one device at a time can send.

          – Ron Maupin
          9 hours ago














        7












        7








        7







        A hub is really just a powered cable that repeats every signal it receives on one interface to all the other interfaces. If two devices transmit at the same time to the receive of the hub interfaces, the hub repeats both signals at the same time to the transmit of all the other hub interfaces, and both signals received will collide at the transmit of the other interfaces, thus you have a collision where all the other interfaces have garbage signals because it is two signals at the same time. The hosts that are sending simultaneously and hear another signal will realize that more than one is is sending at a time, and they will determine that there is a collision.



        Think of it this way, the receive of every hub interface is wired to the transmit of every other interface. Inside the hub, the transmit and receive are connected, even if they are separate at the interface.



        Contrast that with a switch, where each link is terminated at the switch interface, and the switch does not have the interfaces wired together. Instead the switch has logic (usually embedded in hardware) to determine where to send frames it receives on one interface, and to prevent collisions inside the switch.



        A switch is a high-density bridge. The original bridges were like PCs with multiple interfaces. You would not expect a PC with multiple interfaces to have collisions if it received simultaneous frames on multiple interfaces.





        Edit:



        Your comments lead me to believe you still do not understand what I wrote above about hubs.



        The way collisions are detected when using UTP and a hub is by the sending devices hearing another signal while sending. If a device using UTP is configured for half duplex, then it will believe there is a collision when it hears a signal while sending.



        When you have a duplex mismatch, the device configured for full duplex will happily send while receiving from the device configured for half duplex. On the other hand, the device configured for half duplex will believe that there is a collision when it is sending and hears that signal from the device configured for full duplex. That will cause all type of problems because the device configured for half duplex will stop sending the frame (causing a runt), and it will send a jamming signal that the device configured for full duplex is not expecting. The device configured for full duplex will then stop sending its frame.






        share|improve this answer















        A hub is really just a powered cable that repeats every signal it receives on one interface to all the other interfaces. If two devices transmit at the same time to the receive of the hub interfaces, the hub repeats both signals at the same time to the transmit of all the other hub interfaces, and both signals received will collide at the transmit of the other interfaces, thus you have a collision where all the other interfaces have garbage signals because it is two signals at the same time. The hosts that are sending simultaneously and hear another signal will realize that more than one is is sending at a time, and they will determine that there is a collision.



        Think of it this way, the receive of every hub interface is wired to the transmit of every other interface. Inside the hub, the transmit and receive are connected, even if they are separate at the interface.



        Contrast that with a switch, where each link is terminated at the switch interface, and the switch does not have the interfaces wired together. Instead the switch has logic (usually embedded in hardware) to determine where to send frames it receives on one interface, and to prevent collisions inside the switch.



        A switch is a high-density bridge. The original bridges were like PCs with multiple interfaces. You would not expect a PC with multiple interfaces to have collisions if it received simultaneous frames on multiple interfaces.





        Edit:



        Your comments lead me to believe you still do not understand what I wrote above about hubs.



        The way collisions are detected when using UTP and a hub is by the sending devices hearing another signal while sending. If a device using UTP is configured for half duplex, then it will believe there is a collision when it hears a signal while sending.



        When you have a duplex mismatch, the device configured for full duplex will happily send while receiving from the device configured for half duplex. On the other hand, the device configured for half duplex will believe that there is a collision when it is sending and hears that signal from the device configured for full duplex. That will cause all type of problems because the device configured for half duplex will stop sending the frame (causing a runt), and it will send a jamming signal that the device configured for full duplex is not expecting. The device configured for full duplex will then stop sending its frame.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited 8 hours ago

























        answered 12 hours ago









        Ron MaupinRon Maupin

        66.8k1369124




        66.8k1369124








        • 2





          This is the real answer. OP is ignoring all cases except just two endpoints with a crossover cable (or, in a modern setting, any cable) between them.

          – R..
          10 hours ago











        • @R.., the drawing in the question shows a hub, so I answered for a hub connection.

          – Ron Maupin
          9 hours ago











        • This answer explains how the collision occurs when you have a Hub in the topology. Although a late collision can happen when there are two nodes (let's say a switch and a PC), the one is half-duplex and the other is full-duplex. Why a collision does happen in this case, even though there are separate circuits for Tx and Rx, as shown in the graph of my question?

          – Christos Dalamagkas
          9 hours ago











        • Seems that the label "Hub MDI-X" caused some confusion, regarding the point of my question. I edited accordingly.

          – Christos Dalamagkas
          9 hours ago






        • 2





          Because the one with half duplex declares a collision when it hears something while sending. See the answer above.. If a device configured for half-duplex hears another signal while sending, it must assume that there is a collision because it believes that it is half duplex and only one device at a time can send.

          – Ron Maupin
          9 hours ago














        • 2





          This is the real answer. OP is ignoring all cases except just two endpoints with a crossover cable (or, in a modern setting, any cable) between them.

          – R..
          10 hours ago











        • @R.., the drawing in the question shows a hub, so I answered for a hub connection.

          – Ron Maupin
          9 hours ago











        • This answer explains how the collision occurs when you have a Hub in the topology. Although a late collision can happen when there are two nodes (let's say a switch and a PC), the one is half-duplex and the other is full-duplex. Why a collision does happen in this case, even though there are separate circuits for Tx and Rx, as shown in the graph of my question?

          – Christos Dalamagkas
          9 hours ago











        • Seems that the label "Hub MDI-X" caused some confusion, regarding the point of my question. I edited accordingly.

          – Christos Dalamagkas
          9 hours ago






        • 2





          Because the one with half duplex declares a collision when it hears something while sending. See the answer above.. If a device configured for half-duplex hears another signal while sending, it must assume that there is a collision because it believes that it is half duplex and only one device at a time can send.

          – Ron Maupin
          9 hours ago








        2




        2





        This is the real answer. OP is ignoring all cases except just two endpoints with a crossover cable (or, in a modern setting, any cable) between them.

        – R..
        10 hours ago





        This is the real answer. OP is ignoring all cases except just two endpoints with a crossover cable (or, in a modern setting, any cable) between them.

        – R..
        10 hours ago













        @R.., the drawing in the question shows a hub, so I answered for a hub connection.

        – Ron Maupin
        9 hours ago





        @R.., the drawing in the question shows a hub, so I answered for a hub connection.

        – Ron Maupin
        9 hours ago













        This answer explains how the collision occurs when you have a Hub in the topology. Although a late collision can happen when there are two nodes (let's say a switch and a PC), the one is half-duplex and the other is full-duplex. Why a collision does happen in this case, even though there are separate circuits for Tx and Rx, as shown in the graph of my question?

        – Christos Dalamagkas
        9 hours ago





        This answer explains how the collision occurs when you have a Hub in the topology. Although a late collision can happen when there are two nodes (let's say a switch and a PC), the one is half-duplex and the other is full-duplex. Why a collision does happen in this case, even though there are separate circuits for Tx and Rx, as shown in the graph of my question?

        – Christos Dalamagkas
        9 hours ago













        Seems that the label "Hub MDI-X" caused some confusion, regarding the point of my question. I edited accordingly.

        – Christos Dalamagkas
        9 hours ago





        Seems that the label "Hub MDI-X" caused some confusion, regarding the point of my question. I edited accordingly.

        – Christos Dalamagkas
        9 hours ago




        2




        2





        Because the one with half duplex declares a collision when it hears something while sending. See the answer above.. If a device configured for half-duplex hears another signal while sending, it must assume that there is a collision because it believes that it is half duplex and only one device at a time can send.

        – Ron Maupin
        9 hours ago





        Because the one with half duplex declares a collision when it hears something while sending. See the answer above.. If a device configured for half-duplex hears another signal while sending, it must assume that there is a collision because it believes that it is half duplex and only one device at a time can send.

        – Ron Maupin
        9 hours ago











        5














        Great question.



        In full duplex, there is a dedicated channel for traffic from "left to right" and a dedicated channel from traffic from "right to left":



        Dedicated Channel



        Therefore, in full duplex, collisions are impossible -- even if both NIC's transmit at the same time.



        In half-duplex, however, traffic in either direction is meant to only use the wire, one direction at a time. So while physically, there is still dedicated channels, logically if one NIC receives something while it is transmitting, it logs it as a collision. The bits/signal do not actually "collide" on the wire -- a collision counter is simply incremented when the NIC is Receiving and Transmitting at the same time.






        share|improve this answer



















        • 3





          The signals do collide on the wire, even with twisted pair. With three end nodes, two simultaneous signals would collide on the third node.

          – Zac67
          9 hours ago






        • 2





          "The bits/signal do not actually "collide" on the wire" In a hub, as in the drawing in the question, the bits actually do collide on the wire and produce a garbage signal. The hosts that are sending simultaneously and hear another signal will then send a jamming signal to all the other interfaces on the hub.

          – Ron Maupin
          9 hours ago











        • @RonMaupin You're correct of course - I was referring to what would happen when the repeater wouldn't detect/react to the collision.

          – Zac67
          8 hours ago






        • 1





          @Zac67, I wasn't commenting for you, You and I said the same thing at basically the same time.

          – Ron Maupin
          8 hours ago











        • @Zac67 / RonMaupin The OP edited the question confirming they aren't asking about the case of hubs.

          – Eddie
          3 hours ago
















        5














        Great question.



        In full duplex, there is a dedicated channel for traffic from "left to right" and a dedicated channel from traffic from "right to left":



        Dedicated Channel



        Therefore, in full duplex, collisions are impossible -- even if both NIC's transmit at the same time.



        In half-duplex, however, traffic in either direction is meant to only use the wire, one direction at a time. So while physically, there is still dedicated channels, logically if one NIC receives something while it is transmitting, it logs it as a collision. The bits/signal do not actually "collide" on the wire -- a collision counter is simply incremented when the NIC is Receiving and Transmitting at the same time.






        share|improve this answer



















        • 3





          The signals do collide on the wire, even with twisted pair. With three end nodes, two simultaneous signals would collide on the third node.

          – Zac67
          9 hours ago






        • 2





          "The bits/signal do not actually "collide" on the wire" In a hub, as in the drawing in the question, the bits actually do collide on the wire and produce a garbage signal. The hosts that are sending simultaneously and hear another signal will then send a jamming signal to all the other interfaces on the hub.

          – Ron Maupin
          9 hours ago











        • @RonMaupin You're correct of course - I was referring to what would happen when the repeater wouldn't detect/react to the collision.

          – Zac67
          8 hours ago






        • 1





          @Zac67, I wasn't commenting for you, You and I said the same thing at basically the same time.

          – Ron Maupin
          8 hours ago











        • @Zac67 / RonMaupin The OP edited the question confirming they aren't asking about the case of hubs.

          – Eddie
          3 hours ago














        5












        5








        5







        Great question.



        In full duplex, there is a dedicated channel for traffic from "left to right" and a dedicated channel from traffic from "right to left":



        Dedicated Channel



        Therefore, in full duplex, collisions are impossible -- even if both NIC's transmit at the same time.



        In half-duplex, however, traffic in either direction is meant to only use the wire, one direction at a time. So while physically, there is still dedicated channels, logically if one NIC receives something while it is transmitting, it logs it as a collision. The bits/signal do not actually "collide" on the wire -- a collision counter is simply incremented when the NIC is Receiving and Transmitting at the same time.






        share|improve this answer













        Great question.



        In full duplex, there is a dedicated channel for traffic from "left to right" and a dedicated channel from traffic from "right to left":



        Dedicated Channel



        Therefore, in full duplex, collisions are impossible -- even if both NIC's transmit at the same time.



        In half-duplex, however, traffic in either direction is meant to only use the wire, one direction at a time. So while physically, there is still dedicated channels, logically if one NIC receives something while it is transmitting, it logs it as a collision. The bits/signal do not actually "collide" on the wire -- a collision counter is simply incremented when the NIC is Receiving and Transmitting at the same time.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered 12 hours ago









        EddieEddie

        9,39022462




        9,39022462








        • 3





          The signals do collide on the wire, even with twisted pair. With three end nodes, two simultaneous signals would collide on the third node.

          – Zac67
          9 hours ago






        • 2





          "The bits/signal do not actually "collide" on the wire" In a hub, as in the drawing in the question, the bits actually do collide on the wire and produce a garbage signal. The hosts that are sending simultaneously and hear another signal will then send a jamming signal to all the other interfaces on the hub.

          – Ron Maupin
          9 hours ago











        • @RonMaupin You're correct of course - I was referring to what would happen when the repeater wouldn't detect/react to the collision.

          – Zac67
          8 hours ago






        • 1





          @Zac67, I wasn't commenting for you, You and I said the same thing at basically the same time.

          – Ron Maupin
          8 hours ago











        • @Zac67 / RonMaupin The OP edited the question confirming they aren't asking about the case of hubs.

          – Eddie
          3 hours ago














        • 3





          The signals do collide on the wire, even with twisted pair. With three end nodes, two simultaneous signals would collide on the third node.

          – Zac67
          9 hours ago






        • 2





          "The bits/signal do not actually "collide" on the wire" In a hub, as in the drawing in the question, the bits actually do collide on the wire and produce a garbage signal. The hosts that are sending simultaneously and hear another signal will then send a jamming signal to all the other interfaces on the hub.

          – Ron Maupin
          9 hours ago











        • @RonMaupin You're correct of course - I was referring to what would happen when the repeater wouldn't detect/react to the collision.

          – Zac67
          8 hours ago






        • 1





          @Zac67, I wasn't commenting for you, You and I said the same thing at basically the same time.

          – Ron Maupin
          8 hours ago











        • @Zac67 / RonMaupin The OP edited the question confirming they aren't asking about the case of hubs.

          – Eddie
          3 hours ago








        3




        3





        The signals do collide on the wire, even with twisted pair. With three end nodes, two simultaneous signals would collide on the third node.

        – Zac67
        9 hours ago





        The signals do collide on the wire, even with twisted pair. With three end nodes, two simultaneous signals would collide on the third node.

        – Zac67
        9 hours ago




        2




        2





        "The bits/signal do not actually "collide" on the wire" In a hub, as in the drawing in the question, the bits actually do collide on the wire and produce a garbage signal. The hosts that are sending simultaneously and hear another signal will then send a jamming signal to all the other interfaces on the hub.

        – Ron Maupin
        9 hours ago





        "The bits/signal do not actually "collide" on the wire" In a hub, as in the drawing in the question, the bits actually do collide on the wire and produce a garbage signal. The hosts that are sending simultaneously and hear another signal will then send a jamming signal to all the other interfaces on the hub.

        – Ron Maupin
        9 hours ago













        @RonMaupin You're correct of course - I was referring to what would happen when the repeater wouldn't detect/react to the collision.

        – Zac67
        8 hours ago





        @RonMaupin You're correct of course - I was referring to what would happen when the repeater wouldn't detect/react to the collision.

        – Zac67
        8 hours ago




        1




        1





        @Zac67, I wasn't commenting for you, You and I said the same thing at basically the same time.

        – Ron Maupin
        8 hours ago





        @Zac67, I wasn't commenting for you, You and I said the same thing at basically the same time.

        – Ron Maupin
        8 hours ago













        @Zac67 / RonMaupin The OP edited the question confirming they aren't asking about the case of hubs.

        – Eddie
        3 hours ago





        @Zac67 / RonMaupin The OP edited the question confirming they aren't asking about the case of hubs.

        – Eddie
        3 hours ago











        3














        With twisted pair and a repeater hub, the hub is not much more than a digital amplifier. For that it senses a carrier from an incoming signal on one port and switches all other ports to output mode. In this output mode, any additional incoming carrier is a collision. This triggers a jam signal to propagate the collision and make the sender stop transmitting.



        This repeating method mimicks the behavior of the previous, shared media Ethernet variants (10BASE5 & 10BASE2) where repeater were only used as physical segment joints or line extenders. Of course you're correct: twisted pair is a full duplex medium on the wire level where a collision only happens on the upper physical layer and not on the wire itself.



        A repeater cannot permit more than one sender at the same time. Multiple simultaneous transmissions would mix on the output ports and produce unintelligible noise.



        With a duplex mismatch, one link end is in half-duplex and the other in full-duplex mode. Now, when the half-duplex (HDX) side is transmitting, any carrier on its receiver causes a collision to be detected. However, the full-duplex (FDX) side may be happily sending away while it is receiving from the HDX side and it is completely oblivious to the collisions that creates on the far side. The HDX side needs to abort the transmission and sends a jam signal. Since the FDX side cannot detect the alleged collision it detects a partial and therefore damaged frame.



        Low-frequency and small frames have a reasonable chance to get through this duplex mismatch, so a ping could actually work. However, as soon as any serious transmission is trying to get under way, the higher frame frequency and larger size will make the link fail very reliably.



        With unmanaged switches, a duplex mismatch can be very hard to detect, especially when not even the host NICs report their duplex mode properly.



        With managed switches, you usually have port error counters. Increasing collisions on one side and increasing runts and FCS errors on the other side are very strong indications for a duplex mismatch.



        Basically, relying on Auto Negotiation is a very good practice to avoid duplex mismatches. Manually configuring speed and duplex mode is generally prone to creating a mismatch, especially when replacing equipment a few years later. Fortunately the whole half-duplex scheme went away with Gigabit Ethernet and faster.






        share|improve this answer




























          3














          With twisted pair and a repeater hub, the hub is not much more than a digital amplifier. For that it senses a carrier from an incoming signal on one port and switches all other ports to output mode. In this output mode, any additional incoming carrier is a collision. This triggers a jam signal to propagate the collision and make the sender stop transmitting.



          This repeating method mimicks the behavior of the previous, shared media Ethernet variants (10BASE5 & 10BASE2) where repeater were only used as physical segment joints or line extenders. Of course you're correct: twisted pair is a full duplex medium on the wire level where a collision only happens on the upper physical layer and not on the wire itself.



          A repeater cannot permit more than one sender at the same time. Multiple simultaneous transmissions would mix on the output ports and produce unintelligible noise.



          With a duplex mismatch, one link end is in half-duplex and the other in full-duplex mode. Now, when the half-duplex (HDX) side is transmitting, any carrier on its receiver causes a collision to be detected. However, the full-duplex (FDX) side may be happily sending away while it is receiving from the HDX side and it is completely oblivious to the collisions that creates on the far side. The HDX side needs to abort the transmission and sends a jam signal. Since the FDX side cannot detect the alleged collision it detects a partial and therefore damaged frame.



          Low-frequency and small frames have a reasonable chance to get through this duplex mismatch, so a ping could actually work. However, as soon as any serious transmission is trying to get under way, the higher frame frequency and larger size will make the link fail very reliably.



          With unmanaged switches, a duplex mismatch can be very hard to detect, especially when not even the host NICs report their duplex mode properly.



          With managed switches, you usually have port error counters. Increasing collisions on one side and increasing runts and FCS errors on the other side are very strong indications for a duplex mismatch.



          Basically, relying on Auto Negotiation is a very good practice to avoid duplex mismatches. Manually configuring speed and duplex mode is generally prone to creating a mismatch, especially when replacing equipment a few years later. Fortunately the whole half-duplex scheme went away with Gigabit Ethernet and faster.






          share|improve this answer


























            3












            3








            3







            With twisted pair and a repeater hub, the hub is not much more than a digital amplifier. For that it senses a carrier from an incoming signal on one port and switches all other ports to output mode. In this output mode, any additional incoming carrier is a collision. This triggers a jam signal to propagate the collision and make the sender stop transmitting.



            This repeating method mimicks the behavior of the previous, shared media Ethernet variants (10BASE5 & 10BASE2) where repeater were only used as physical segment joints or line extenders. Of course you're correct: twisted pair is a full duplex medium on the wire level where a collision only happens on the upper physical layer and not on the wire itself.



            A repeater cannot permit more than one sender at the same time. Multiple simultaneous transmissions would mix on the output ports and produce unintelligible noise.



            With a duplex mismatch, one link end is in half-duplex and the other in full-duplex mode. Now, when the half-duplex (HDX) side is transmitting, any carrier on its receiver causes a collision to be detected. However, the full-duplex (FDX) side may be happily sending away while it is receiving from the HDX side and it is completely oblivious to the collisions that creates on the far side. The HDX side needs to abort the transmission and sends a jam signal. Since the FDX side cannot detect the alleged collision it detects a partial and therefore damaged frame.



            Low-frequency and small frames have a reasonable chance to get through this duplex mismatch, so a ping could actually work. However, as soon as any serious transmission is trying to get under way, the higher frame frequency and larger size will make the link fail very reliably.



            With unmanaged switches, a duplex mismatch can be very hard to detect, especially when not even the host NICs report their duplex mode properly.



            With managed switches, you usually have port error counters. Increasing collisions on one side and increasing runts and FCS errors on the other side are very strong indications for a duplex mismatch.



            Basically, relying on Auto Negotiation is a very good practice to avoid duplex mismatches. Manually configuring speed and duplex mode is generally prone to creating a mismatch, especially when replacing equipment a few years later. Fortunately the whole half-duplex scheme went away with Gigabit Ethernet and faster.






            share|improve this answer













            With twisted pair and a repeater hub, the hub is not much more than a digital amplifier. For that it senses a carrier from an incoming signal on one port and switches all other ports to output mode. In this output mode, any additional incoming carrier is a collision. This triggers a jam signal to propagate the collision and make the sender stop transmitting.



            This repeating method mimicks the behavior of the previous, shared media Ethernet variants (10BASE5 & 10BASE2) where repeater were only used as physical segment joints or line extenders. Of course you're correct: twisted pair is a full duplex medium on the wire level where a collision only happens on the upper physical layer and not on the wire itself.



            A repeater cannot permit more than one sender at the same time. Multiple simultaneous transmissions would mix on the output ports and produce unintelligible noise.



            With a duplex mismatch, one link end is in half-duplex and the other in full-duplex mode. Now, when the half-duplex (HDX) side is transmitting, any carrier on its receiver causes a collision to be detected. However, the full-duplex (FDX) side may be happily sending away while it is receiving from the HDX side and it is completely oblivious to the collisions that creates on the far side. The HDX side needs to abort the transmission and sends a jam signal. Since the FDX side cannot detect the alleged collision it detects a partial and therefore damaged frame.



            Low-frequency and small frames have a reasonable chance to get through this duplex mismatch, so a ping could actually work. However, as soon as any serious transmission is trying to get under way, the higher frame frequency and larger size will make the link fail very reliably.



            With unmanaged switches, a duplex mismatch can be very hard to detect, especially when not even the host NICs report their duplex mode properly.



            With managed switches, you usually have port error counters. Increasing collisions on one side and increasing runts and FCS errors on the other side are very strong indications for a duplex mismatch.



            Basically, relying on Auto Negotiation is a very good practice to avoid duplex mismatches. Manually configuring speed and duplex mode is generally prone to creating a mismatch, especially when replacing equipment a few years later. Fortunately the whole half-duplex scheme went away with Gigabit Ethernet and faster.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered 8 hours ago









            Zac67Zac67

            30.6k21960




            30.6k21960























                1














                Suppose machine A starts sending data to machine B. As the packet begins to be sent, machine C starts sending different data to machine B. There is only one signal path to machine B, so the transmissions from A and C collide and B cannot possibly receive both of them.



                The fact that a different circuit is used for transmissions from machine B, to machine A, and to machine C doesn't help. All that's happening is that A and C are trying to transmit to machine B at the same time and there is only one signal path to machine B.






                share|improve this answer




























                  1














                  Suppose machine A starts sending data to machine B. As the packet begins to be sent, machine C starts sending different data to machine B. There is only one signal path to machine B, so the transmissions from A and C collide and B cannot possibly receive both of them.



                  The fact that a different circuit is used for transmissions from machine B, to machine A, and to machine C doesn't help. All that's happening is that A and C are trying to transmit to machine B at the same time and there is only one signal path to machine B.






                  share|improve this answer


























                    1












                    1








                    1







                    Suppose machine A starts sending data to machine B. As the packet begins to be sent, machine C starts sending different data to machine B. There is only one signal path to machine B, so the transmissions from A and C collide and B cannot possibly receive both of them.



                    The fact that a different circuit is used for transmissions from machine B, to machine A, and to machine C doesn't help. All that's happening is that A and C are trying to transmit to machine B at the same time and there is only one signal path to machine B.






                    share|improve this answer













                    Suppose machine A starts sending data to machine B. As the packet begins to be sent, machine C starts sending different data to machine B. There is only one signal path to machine B, so the transmissions from A and C collide and B cannot possibly receive both of them.



                    The fact that a different circuit is used for transmissions from machine B, to machine A, and to machine C doesn't help. All that's happening is that A and C are trying to transmit to machine B at the same time and there is only one signal path to machine B.







                    share|improve this answer












                    share|improve this answer



                    share|improve this answer










                    answered 6 hours ago









                    David SchwartzDavid Schwartz

                    28416




                    28416























                        0














                        To understand this you need to understand the historical context.



                        Originally Ethernet used a shared coaxial cable. Only one device could successfully transmit on this at a time. If two devices transmitted at the same time it was considered a collision.



                        Then repeaters came along, to extend the distance and increase the number of nodes. A repeater would detect which port is transmitting, then it would repeat that signal out on the other ports. To keep the collision detection working repeaters had to have some functionality for ensuring that all nodes detected a collision. The first repeaters only had two ports, but later repeaters could have multiple ports and these became known as hubs, especially when used in conjunction with twisted-pair wiring. Repeaters were pretty dumb devices, they would regenerate the electrical signals,



                        Then 10BASE-T came in, which as you have noticed has dedicated data channels for each direction. Nevertheless it still needed to fit into the existing model, so by default it operated in a "half-duplex" mode where it emulated a coaxial cable. The signals did not in-fact collide on the wire but the transceivers acted as-if they did and the repeaters would take the same steps as before to ensure this was seen across the network.



                        Twisted pair Ethernet can also support a "full-duplex" mode. In this mode all of the collision-related hardware is disabled and both ends can transmit at any time. However this mode brought a couple of major downsides.




                        • It was incompatible with repeater-hubs. Without the collision detection mechanisms hubs would have no way of handling two devices transmitting at the same time.

                        • Both ends of a link to be set-up for the same duplex mode, if they are not then bad things will happen.


                        These issues meant that in practice 10BASE-T systems nearly always operated in half-duplex mode.



                        For 100BASE-TX the situation improved dramatically. Ethernet switches (technically fast multi-port bridges) came down in price to the point that dumb repeater hubs could be eliminated. Auto-negotiation allowed network cards to establish full-duplex connections without error-prone manual configuration. If you connect two 100BASE-TX NICs together with a crossover cable or connect a 100BASE-TX NIC to a switch and don't take steps to manually override things they will almost certainly negotiate full-duplex mode.



                        1000BASE-T theoretically has a half-duplex mode which some NICs claim to support and there was a specification for gigabit multiport repeaters, but I have never seen any evidence that anyone ever sold one. In practice a gigabit link will almost-certainly be running in full-duplex mode.



                        Faster speeds abandoned the half-duplex mode entirely.






                        share|improve this answer




























                          0














                          To understand this you need to understand the historical context.



                          Originally Ethernet used a shared coaxial cable. Only one device could successfully transmit on this at a time. If two devices transmitted at the same time it was considered a collision.



                          Then repeaters came along, to extend the distance and increase the number of nodes. A repeater would detect which port is transmitting, then it would repeat that signal out on the other ports. To keep the collision detection working repeaters had to have some functionality for ensuring that all nodes detected a collision. The first repeaters only had two ports, but later repeaters could have multiple ports and these became known as hubs, especially when used in conjunction with twisted-pair wiring. Repeaters were pretty dumb devices, they would regenerate the electrical signals,



                          Then 10BASE-T came in, which as you have noticed has dedicated data channels for each direction. Nevertheless it still needed to fit into the existing model, so by default it operated in a "half-duplex" mode where it emulated a coaxial cable. The signals did not in-fact collide on the wire but the transceivers acted as-if they did and the repeaters would take the same steps as before to ensure this was seen across the network.



                          Twisted pair Ethernet can also support a "full-duplex" mode. In this mode all of the collision-related hardware is disabled and both ends can transmit at any time. However this mode brought a couple of major downsides.




                          • It was incompatible with repeater-hubs. Without the collision detection mechanisms hubs would have no way of handling two devices transmitting at the same time.

                          • Both ends of a link to be set-up for the same duplex mode, if they are not then bad things will happen.


                          These issues meant that in practice 10BASE-T systems nearly always operated in half-duplex mode.



                          For 100BASE-TX the situation improved dramatically. Ethernet switches (technically fast multi-port bridges) came down in price to the point that dumb repeater hubs could be eliminated. Auto-negotiation allowed network cards to establish full-duplex connections without error-prone manual configuration. If you connect two 100BASE-TX NICs together with a crossover cable or connect a 100BASE-TX NIC to a switch and don't take steps to manually override things they will almost certainly negotiate full-duplex mode.



                          1000BASE-T theoretically has a half-duplex mode which some NICs claim to support and there was a specification for gigabit multiport repeaters, but I have never seen any evidence that anyone ever sold one. In practice a gigabit link will almost-certainly be running in full-duplex mode.



                          Faster speeds abandoned the half-duplex mode entirely.






                          share|improve this answer


























                            0












                            0








                            0







                            To understand this you need to understand the historical context.



                            Originally Ethernet used a shared coaxial cable. Only one device could successfully transmit on this at a time. If two devices transmitted at the same time it was considered a collision.



                            Then repeaters came along, to extend the distance and increase the number of nodes. A repeater would detect which port is transmitting, then it would repeat that signal out on the other ports. To keep the collision detection working repeaters had to have some functionality for ensuring that all nodes detected a collision. The first repeaters only had two ports, but later repeaters could have multiple ports and these became known as hubs, especially when used in conjunction with twisted-pair wiring. Repeaters were pretty dumb devices, they would regenerate the electrical signals,



                            Then 10BASE-T came in, which as you have noticed has dedicated data channels for each direction. Nevertheless it still needed to fit into the existing model, so by default it operated in a "half-duplex" mode where it emulated a coaxial cable. The signals did not in-fact collide on the wire but the transceivers acted as-if they did and the repeaters would take the same steps as before to ensure this was seen across the network.



                            Twisted pair Ethernet can also support a "full-duplex" mode. In this mode all of the collision-related hardware is disabled and both ends can transmit at any time. However this mode brought a couple of major downsides.




                            • It was incompatible with repeater-hubs. Without the collision detection mechanisms hubs would have no way of handling two devices transmitting at the same time.

                            • Both ends of a link to be set-up for the same duplex mode, if they are not then bad things will happen.


                            These issues meant that in practice 10BASE-T systems nearly always operated in half-duplex mode.



                            For 100BASE-TX the situation improved dramatically. Ethernet switches (technically fast multi-port bridges) came down in price to the point that dumb repeater hubs could be eliminated. Auto-negotiation allowed network cards to establish full-duplex connections without error-prone manual configuration. If you connect two 100BASE-TX NICs together with a crossover cable or connect a 100BASE-TX NIC to a switch and don't take steps to manually override things they will almost certainly negotiate full-duplex mode.



                            1000BASE-T theoretically has a half-duplex mode which some NICs claim to support and there was a specification for gigabit multiport repeaters, but I have never seen any evidence that anyone ever sold one. In practice a gigabit link will almost-certainly be running in full-duplex mode.



                            Faster speeds abandoned the half-duplex mode entirely.






                            share|improve this answer













                            To understand this you need to understand the historical context.



                            Originally Ethernet used a shared coaxial cable. Only one device could successfully transmit on this at a time. If two devices transmitted at the same time it was considered a collision.



                            Then repeaters came along, to extend the distance and increase the number of nodes. A repeater would detect which port is transmitting, then it would repeat that signal out on the other ports. To keep the collision detection working repeaters had to have some functionality for ensuring that all nodes detected a collision. The first repeaters only had two ports, but later repeaters could have multiple ports and these became known as hubs, especially when used in conjunction with twisted-pair wiring. Repeaters were pretty dumb devices, they would regenerate the electrical signals,



                            Then 10BASE-T came in, which as you have noticed has dedicated data channels for each direction. Nevertheless it still needed to fit into the existing model, so by default it operated in a "half-duplex" mode where it emulated a coaxial cable. The signals did not in-fact collide on the wire but the transceivers acted as-if they did and the repeaters would take the same steps as before to ensure this was seen across the network.



                            Twisted pair Ethernet can also support a "full-duplex" mode. In this mode all of the collision-related hardware is disabled and both ends can transmit at any time. However this mode brought a couple of major downsides.




                            • It was incompatible with repeater-hubs. Without the collision detection mechanisms hubs would have no way of handling two devices transmitting at the same time.

                            • Both ends of a link to be set-up for the same duplex mode, if they are not then bad things will happen.


                            These issues meant that in practice 10BASE-T systems nearly always operated in half-duplex mode.



                            For 100BASE-TX the situation improved dramatically. Ethernet switches (technically fast multi-port bridges) came down in price to the point that dumb repeater hubs could be eliminated. Auto-negotiation allowed network cards to establish full-duplex connections without error-prone manual configuration. If you connect two 100BASE-TX NICs together with a crossover cable or connect a 100BASE-TX NIC to a switch and don't take steps to manually override things they will almost certainly negotiate full-duplex mode.



                            1000BASE-T theoretically has a half-duplex mode which some NICs claim to support and there was a specification for gigabit multiport repeaters, but I have never seen any evidence that anyone ever sold one. In practice a gigabit link will almost-certainly be running in full-duplex mode.



                            Faster speeds abandoned the half-duplex mode entirely.







                            share|improve this answer












                            share|improve this answer



                            share|improve this answer










                            answered 5 hours ago









                            Peter GreenPeter Green

                            7,72421227




                            7,72421227






















                                Christos Dalamagkas is a new contributor. Be nice, and check out our Code of Conduct.










                                draft saved

                                draft discarded


















                                Christos Dalamagkas is a new contributor. Be nice, and check out our Code of Conduct.













                                Christos Dalamagkas is a new contributor. Be nice, and check out our Code of Conduct.












                                Christos Dalamagkas is a new contributor. Be nice, and check out our Code of Conduct.
















                                Thanks for contributing an answer to Network Engineering Stack Exchange!


                                • Please be sure to answer the question. Provide details and share your research!

                                But avoid



                                • Asking for help, clarification, or responding to other answers.

                                • Making statements based on opinion; back them up with references or personal experience.


                                To learn more, see our tips on writing great answers.




                                draft saved


                                draft discarded














                                StackExchange.ready(
                                function () {
                                StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fnetworkengineering.stackexchange.com%2fquestions%2f57521%2fhow-exactly-does-an-ethernet-collision-happen-in-the-cable-since-nodes-use-diff%23new-answer', 'question_page');
                                }
                                );

                                Post as a guest















                                Required, but never shown





















































                                Required, but never shown














                                Required, but never shown












                                Required, but never shown







                                Required, but never shown

































                                Required, but never shown














                                Required, but never shown












                                Required, but never shown







                                Required, but never shown







                                Popular posts from this blog

                                Loup dans la culture

                                How to solve the problem of ntp “Unable to contact time server” from KDE?

                                ASUS Zenbook UX433/UX333 — Configure Touchpad-embedded numpad on Linux