collisions on a 100% full duplex

"100% full duplex" ethernets often aren't. It is not uncommon for a small number of devices to not know (or to get confused) over whether they should use full or half duplex. If one end of a fully-switched segment thinks that the link is half duplex and the other end thinks that it is fully duplex, then you will get collisions.

In this context, note that it still is not uncommon for printers to be half-duplex. I don't know why they bother, but it must save them 50 cents in manufacturering costs or something like that. Printers seldom send much data -out- so I guess manufacturers think that full duplex is not important. These days, though, people mostly expect devices to be full duplex, and the mismatch in expectations can lead to mismatched configurations...

Collision is an Ethernet term which means "contention for access to the wire."

In that strict sense, I'd say no, you can't have contention if there's only one host in the host-switch link, and both directions can be active simultaneously. The host and the switch can transmit whenever they're ready.

In the larger sense, there can certainly still be contention for network assets, though. If not on individual Ethernet links, certainly at switches and hosts (e.g. servers). Any part of the network where flows merge will create the potential for contention, which is why flow control exists.

Bert

Which wire is used for half duplex signals?

Is it the full duplex receive wire or the full duplex transmit wire?

Thanks.

Umm, that's 'pair'.

Absolutely! Which other one would they use?

[Transmit on one side is receive on the other side. Half duplex just means you can't talk while you are hearing someone else, the wiring and transcievers are the same.]

Maybe I see your confusion?

First, the pairs are used by driving one wire say +ve and the other wire -ve.

I have made quite a lot of this up but I think that it is about right.

In HD the Tx is connected to the Rx /inside/ both the transmitting ends. This is designed to /cause/ collisions in the event that the timing of the signals (not of course the timing of the bit signalling clock, but the timing of the frames) results in a colision. The reason that it is necessary to 'create' these internal collisions is that the cable could be connected to a repeater and on the other side of that repeater thre could be a coaxial cable segment where the collision will occur anyway.

A central point of the Ethernet contention resolution mechanism is that /all/ stations on the segment agree when there has been a collision.

This 'feedback' link allows that.

You might consider posting this to comp.dcom.lans.ethernet where the Ethernet experts hang out.

(snip on full duplex ethernet)

At least for TCP there will usually be an ACK for every data packet, which can easily cause a collision with the next data packet. Note, though, that ethernet can run at 50% collusion rate and still have a very large fraction of the bandwidth available for data.

-- glen

Because of the Nagle algorithm, it would be an ACK for every second data packet.

Indeed, it will work quite efficiently even at "collision rates" in the several hundred percent range.

Would you be kind enough to define "several hundred percent"? Is a puzzlement to me how you can have more than one collision per frame.

It is possible to have collisions on subsequent attempts by the NIC to resend the same frame. I forget how many are allowed by the spec until they are declared "excessive" and the frame is finally dropped by the NIC.

rick jones

I agree. 15 collisions max, but the backoff does not increase after the

10th, I believe (from memory).

Bert