Tom Carpenter wrote:
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.
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
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
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).