[Udpcast] "--full-duplex" option in cast-o-matic initrd images
tomc at bio.umass.edu
Sun Jan 31 05:17:31 CET 2010
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
More information about the Udpcast