[Udpcast] "--full-duplex" option in cast-o-matic initrd images

Alain Knaff alain at knaff.lu
Sun Jan 31 08:46:29 CET 2010

Tom Carpenter wrote:
> Alain,
> Are you saying udp-receiver is effectively configured to use
> the --half-duplex option?

No, I'm not saying such a thing.

> Is the full-duplex/half-duplex
> behavior of ethernet adapters independent of the --full-duplex/
> --half-duplex setting used for udp-sender

Well, it is a different thing (see my previous mail), but it works best
if it matches the setting on the ethernet adapter.

> and udp-receiver?

There is no --full-duplex/--half-duplex setting on the udp-receiver. The
reason for this is that the receiver only "talks" when asked to by the
sender, so it's in the sender's hands whether we can get in a situation
where receiver replies collide with further sends or not.

> I'm asking because I've seen switch ports (which are configured
> to auto negotiate speed and duplex settings) sometimes reported
> as being in half-duplex mode and sometimes in full-duplex mode
> when connected to systems running a cast-o-matic udp-receiver
> image.

Weird. Udp-sender does not change the settings on the ethernet adapter.
However, if neither --full-duplex, nor --half-duplex are given, udpcast
tries to _read_ the settings on the ethernet adapter (in order to use
the same setting internally as the adapter).

> This makes me think that the adapters, the switch, or
> perhaps both don't auto negotiate well and that I might be better
> off not relying on auto negotiation.

This is a well known problem on some switches, and independent of udpcast.

> Could one udp-receiver, that
> didn't auto-negotiate the ethernet adapter's duplex setting,
> cause the transmission to a larger group to hang shortly after
> the transmission began?

It might become very slow due to the high number of collisions, but it
shouldn't hang.

Basically, on a low level, if both ends of the ethernet link are
mismatched, the following will happen:
1. The full-duplex end card will not bother try to detect any
collisions, and happily send even if the far end is talking
2. The half-duplex end card will (wrongly...) assume a collision if it
detects the far end talking while itself sends, and stop and retransmit.

... so in the event that the communication is truly bidirectional, lots
of packets will be lost and retransmitted, slowing down the connection.

However, if on the high level, the communication is not bidirectional
(--half-duplex setting on the receiver), then this should
(theoretically) not be an issue at all, because the case outlines above
would never occur. Unless udpcast packets collided with packets of
other, unrelated activity.

It might be interesting to attempt the transmission with the switch
containing the udpcasted set disconnected from everything else (no
uplink, and no machines not participating connected to it).

> I've had sessions to groups of machines
> fail in this way, then broadcast to all but the problem system,
> and then unicast an image to the problem system (at 90-95Mb/s
> on 100Mb/s link).

Best regards,


More information about the Udpcast mailing list