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,
Alain