Alain,
Are you saying udp-receiver is effectively configured to use the --half-duplex option? Is the full-duplex/half-duplex behavior of ethernet adapters independent of the --full-duplex/ --half-duplex setting used for udp-sender and udp-receiver? 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. 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. 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? 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).
Alain Knaff wrote:
Tom Carpenter wrote:
Jens, et al,
Careless reading on my part.
Sorry to revisit this. Do you know if udp-receiver is configured to only use half-duplex mode? If so, why have a "--full-duplex" option for udp-sender if udp-receiver can only operate in half-duplex mode?
A related question: do the --full-duplex/--half-duplex options configure udp-sender's behavior, the network adapter, or both?
The full-duplex mode only configures udp-sender's behavior (whether it sends out more data packets while waiting for the acknowledgement of the previous slice or not).
So, this is an option that's only relevant on the sender.
I've changed cast-o-matic so that you can now enter options which only apply to the receiver, or only to the sender
Regards,
Alain