Is "--half-duplex" the default setting used by cast-o-matic images? I tried adding "--full-duplex" to the "Additional Udpcast command-line parameters" field of the current "Cast-o-matic Stage 2" configuration page, but I get the error "unrecognized option '--full-duplex'". (Note: '--full-duplex' was entered as the first of two command-line parameters.)
Hello Tom,
could it be that you specified --full-duplex as a command for the receiver? I think it doesn't make sense for the receiver as the part that spits the traffic and therefore has to take care of the amount of traffic is solely the sender. However, at my end the sender happily eats the option whereas the receiver errors out.
Kind regards Jens
On Tue, Jan 19, 2010 at 7:45 PM, Tom Carpenter tomc@bio.umass.edu wrote:
Is "--half-duplex" the default setting used by cast-o-matic images? I tried adding "--full-duplex" to the "Additional Udpcast command-line parameters" field of the current "Cast-o-matic Stage 2" configuration page, but I get the error "unrecognized option '--full-duplex'". (Note: '--full-duplex' was entered as the first of two command-line parameters.)
-- Tom Carpenter
Jens,
Yes, I did try to use "--full-duplex" as an option for a 'receiver' image. Based my reading of the information on this page
-------------------------------- http://udpcast.linux.lu/cmd.html
Networking options
The following networking options should be supplied both on the sender and the receivers:
--full-duplex
and
--half-duplex
--------------------------------
I thought it would at least be possible to use "--full-duplex" as an option (whether it was a good idea or not). But, more of the story follows.
I booted twenty PCs using a cast-o-matic 'receiver' image, built without specifying "--full-duplex" (which, I assume uses "--half-duplex" by default - given information on the same web page as mentioned above). I used the "--full-duplex" switch to start the 'sender', but the transfer stopped after roughly 160MB had been sent. I started a new transfer session; 'receiver' systems were booted with the same cast-o-matic image, the udpcast sender was started using the "--half-duplex" switch, and all went relatively well, aside from a lot of 'not ready' messages from the receivers on the 'sender' console.
Not to distract from the main question of whether one can specify half- or full-duplex in cast-o-matic images, I'll also mention that the 'receiver' PCs don't seem to be auto negotiating half/full duplex connections with the switch to which they're connected.
Jens Breuer wrote:
Hello Tom,
could it be that you specified --full-duplex as a command for the receiver? I think it doesn't make sense for the receiver as the part that spits the traffic and therefore has to take care of the amount of traffic is solely the sender. However, at my end the sender happily eats the option whereas the receiver errors out.
Kind regards Jens
On Tue, Jan 19, 2010 at 7:45 PM, Tom Carpenter tomc@bio.umass.edu wrote:
Is "--half-duplex" the default setting used by cast-o-matic images? I tried adding "--full-duplex" to the "Additional Udpcast command-line parameters" field of the current "Cast-o-matic Stage 2" configuration page, but I get the error "unrecognized option '--full-duplex'". (Note: '--full-duplex' was entered as the first of two command-line parameters.)
-- Tom Carpenter
Udpcast mailing list Udpcast@udpcast.linux.lu https://udpcast.linux.lu/cgi-bin/mailman/listinfo/udpcast
Hello Tom,
this is only partially true. The section indeed begins with "The following networking options should be supplied both on the sender and the receivers:" But if you read on further you'll find "The following networking options should be supplied only on the sender:" right before the explanation of --mcast-data-address which is in the same block as --full-duplex.
I would agree that this is not well highlighted in the documentation.
To be honest I am not sure if I explicitly used --full-duplex in the past (and now) so I am probably not of much help for the question of autonegotioation.
Kind regards Jens
On Tue, Jan 19, 2010 at 9:53 PM, Tom Carpenter tomc@bio.umass.edu wrote:
Jens,
Yes, I did try to use "--full-duplex" as an option for a 'receiver' image. Based my reading of the information on this page
http://udpcast.linux.lu/cmd.html
Networking options
The following networking options should be supplied both on the sender and the receivers:
--full-duplex
and
--half-duplex
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?
Jens Breuer wrote:
Hello Tom,
this is only partially true. The section indeed begins with "The following networking options should be supplied both on the sender and the receivers:" But if you read on further you'll find "The following networking options should be supplied only on the sender:" right before the explanation of --mcast-data-address which is in the same block as --full-duplex.
I would agree that this is not well highlighted in the documentation.
To be honest I am not sure if I explicitly used --full-duplex in the past (and now) so I am probably not of much help for the question of autonegotioation.
Kind regards Jens
On Tue, Jan 19, 2010 at 9:53 PM, Tom Carpenter tomc@bio.umass.edu wrote:
Jens,
Yes, I did try to use "--full-duplex" as an option for a 'receiver' image. Based my reading of the information on this page
http://udpcast.linux.lu/cmd.html
Networking options
The following networking options should be supplied both on the sender and the receivers:
--full-duplex
and
--half-duplex
Udpcast mailing list Udpcast@udpcast.linux.lu https://udpcast.linux.lu/cgi-bin/mailman/listinfo/udpcast
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
Jens Breuer wrote:
Hello Tom, this is only partially true. The section indeed begins with "The following networking options should be supplied both on the sender and the receivers:" But if you read on further you'll find "The following networking options should be supplied only on the sender:" right before the explanation of --mcast-data-address which is in the same block as --full-duplex.
I would agree that this is not well highlighted in the documentation.
To be honest I am not sure if I explicitly used --full-duplex in the past (and now) so I am probably not of much help for the question of autonegotioation.
Kind regards Jens
On Tue, Jan 19, 2010 at 9:53 PM, Tom Carpenter tomc@bio.umass.edu wrote:
Jens,
Yes, I did try to use "--full-duplex" as an option for a 'receiver' image. Based my reading of the information on this page
http://udpcast.linux.lu/cmd.html
Networking options
The following networking options should be supplied both on the sender and the receivers:
--full-duplex
and
--half-duplex
Udpcast mailing list Udpcast@udpcast.linux.lu https://udpcast.linux.lu/cgi-bin/mailman/listinfo/udpcast
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
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
-
Alain Knaff -
Jens Breuer -
Tom Carpenter