Talk:Carrier-sense multiple access with collision detection

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Low	This article has been rated as Low-importance on the project's importance scale.
	This article is supported by Networking task force (assessed as Mid-importance).

The Jam signal is used in CSMA/CA and not in CSMA/CD

I don't know if this is true or not but the article says it IS used in CSMA/CD at the top and then contradicts it.. —Preceding unsigned comment added by Pyxs (talk • contribs) 14:45, 29 August 2009 (UTC)[reply]

Nodes must continue to transmit *something* for the minimum packet time after detecting a collision, WHAT they transmit (more of the packet data or an explicit jam signal) doesn't matter to the algorithm.

Repeaters must also be able to repeat a collision so that all nodes in the network see it. Plugwash (talk) 10:36, 28 September 2011 (UTC)[reply]

NO ITS NOT, this is false information

After "a carrier sensing scheme is used" someone put "NO ITS NOT, this is false information". I don't know whether it's true or not, but this isn't the right way to inform readers. —Preceding unsigned comment added by 82.49.187.14 (talk) 15:01, 25 June 2008 (UTC)[reply]

how to reduce collision

references

the references section needs some cleanup, it doesn't fit wiki standards.

Stdazi 15:18, 6 April 2007 (UTC)[reply]

Collision detection is not done by CRC

The article implies that collision detection is based on CRC. This is incorrect. It is an analog process -- the transceiver monitors the wire while it is sending, and if it detects a signal on the wire that differs from what it sent (because another transceiver is also contributing) that is a collision.

Collision detection is a physical layer function. CRC handling is a MAC layer function. The two are not connected.

Paul Koning 20:35, 16 April 2007 (UTC)[reply]

I thought collision detection used a change in the voltage on the wire... Not saying that's right, necessarily... DavidChipman (talk) 16:03, 28 August 2012 (UTC)[reply]

Throughput

Some books on networking have curves in which one can see the maximum throughput of 0.1-persistent CSMA, 0.01-persistent CSMA, ALOHA etc. in comparison on a single chart. Such a chart is extremely helpful to understand the performance of the different multiple access methodss. Subwy (talk) 15:32, 21 July 2008 (UTC)[reply]

No longer utilize

The article asserts "Modern Ethernet networks ... no longer utilize CSMA/CD". That is true in the sense that collisions will not normally occur (because there is one device per port), but surely all switches still have collision detection on each port? A recent edit (diff) could be read as suggesting that CD is no longer implemented and I'm pretty sure the section needs to be rewritten. Thoughts? Johnuniq (talk) 22:48, 12 November 2010 (UTC)[reply]

Supporting something and using it aren't the same thing. Modern ethernet gear supports CSMA/CD because it's needed for interoperability with legacy equipment but in a network built out modern gear it won't be used as the links will be running in full duplex mode (where collisions can't happen). Plugwash (talk) 17:07, 29 July 2011 (UTC)[reply]

The IEEE Std 802.3-2008 standard notes that there are two modes of operation for the MAC sublayer, half duplex and full duplex. It mentions that, in case of full duplex operation, as 'there is no contention for the use of a shared medium, the multiple access (i.e. CSMA/CD) algorithms are not necessary' (Section One, p.55). There are two (three) remarks one can make to that statement.

First remark is that 'not necessary' not equates to 'not to be used'.

The second remark is that modern networking gear often supports autonegotiation by default, and autonegotiation defaults back to half duplex in case of autonegotiation disabled on the other side of the link. Hence it is quite likely that CSMA/CD is operational (used) by default on modern networking gear.

Since this comment has a lot to do with the above (but could be its own topic) I'll put it here: Auto on one side and full on the other side will cause Late Collisions. The Full duplex side is not going to do collision detection (so full should not be used on a "bus" shaped network, or anywhere more than two NICs touch the same wire.) The Late Collision Section should mention that one side on "auto" and the other side on "full" will cause them too. The "auto" side is running at "half" in this situation. — Preceding unsigned comment added by 184.7.23.146 (talk) 16:05, 19 October 2016 (UTC)[reply]

Finally, I highly suspect it will be a long time before I get to see the miracle of a collision-free enterprise network, whatever theoreticals the standards may describe. — Preceding unsigned comment added by 109.131.47.132 (talk) 15:53, 3 October 2011 (UTC)[reply]

Misleading

"IEEE 802.3 deprecated Ethernet repeaters, CSMA/CD, and half-duplex operation in 2011,[2]" misleading: The reference points to IEEE 802.3, 3 paragraphs which are all about deprecating repeaters, nothing else. But the text says "CSMA/CD, and half-duplex operation" was deprecated too. Can't see that it was, am pretty sure it wasn't.

99.9% of half-duplex use is because you're connected to a repeater (hub). Most NICs and switches in general support full-duplex mode. --Zac67 (talk) 13:49, 22 November 2019 (UTC)[reply]

Yes, but I think the point being made here is that half-duplex in NICs has not been deprecated by IEEE 802.3. We could say something like, "IEEE 802.3 deprecated Ethernet repeaters in 2011 making CSMA/CD and half-duplex operation less common and less important," ~Kvng (talk) 14:50, 25 November 2019 (UTC)[reply]

Very good, that's more precise. --Zac67 (talk) 17:46, 25 November 2019 (UTC)[reply]

Done ~Kvng (talk) 15:06, 28 November 2019 (UTC)[reply]