How exactly does an Ethernet collision happen in the cable, since nodes use different circuits for Tx and Rx?
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?
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
New contributor
add a comment |
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?
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
New contributor
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
add a comment |
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?
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
New contributor
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?
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
ethernet layer1 utp autonegotiation ieee-802.3x
New contributor
New contributor
edited 9 hours ago
Christos Dalamagkas
New contributor
asked 14 hours ago
Christos DalamagkasChristos Dalamagkas
363
363
New contributor
New contributor
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
add a comment |
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
add a comment |
5 Answers
5
active
oldest
votes
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.
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
|
show 2 more comments
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":
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.
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
add a comment |
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.
add a comment |
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.
add a comment |
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.
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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.
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
|
show 2 more comments
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.
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
|
show 2 more comments
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.
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.
edited 8 hours ago
answered 12 hours ago
Ron Maupin♦Ron 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
|
show 2 more comments
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
|
show 2 more comments
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":
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.
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
add a comment |
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":
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.
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
add a comment |
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":
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.
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":
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.
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
add a comment |
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
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered 8 hours ago
Zac67Zac67
30.6k21960
30.6k21960
add a comment |
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered 6 hours ago
David SchwartzDavid Schwartz
28416
28416
add a comment |
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered 5 hours ago
Peter GreenPeter Green
7,72421227
7,72421227
add a comment |
add a comment |
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.
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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