From gp at lyngbjerggaardskolen.dk  Thu Jan 14 13:24:12 2010
From: gp at lyngbjerggaardskolen.dk (Gunner Poulsen)
Date: Thu, 14 Jan 2010 13:24:12 +0100
Subject: [Udpcast] Problem with Hitachi hard disk in 20091230 and posible
	before
Message-ID: <20100114120711.M88508@lyngbjerggaardskolen.dk>

Dear friends
I use UDP-cast in my work as administrator on a school. It has worked
brilliant for years :-)
Now we have got 35 new labtops that I have to clone. But UDP-Cast can't find
the harddisk :-(
The hard discs are: ATA Hitachi hts542525k9sa00
UDP-cast just comes up with OTHER as harddisk partions to clone.
Can anyone help?
I beleve it is a fault in the driver.

Med venlig hilsen Gunner Poulsen
Lærer på http://www.lyngbjerggaardskolen.dk
Mobil: 30 24 58 72



From gp at lyngbjerggaardskolen.dk  Thu Jan 14 14:12:17 2010
From: gp at lyngbjerggaardskolen.dk (Gunner Poulsen)
Date: Thu, 14 Jan 2010 14:12:17 +0100
Subject: [Udpcast] Problem with Hitachi hard disk in 20091230 and
	posible before
In-Reply-To: <20100114130154.M2191@lyngbjerggaardskolen.dk>
References: <20100114120711.M88508@lyngbjerggaardskolen.dk>
	<b8248e301001140450m3b058394wd80d0b7268aa9921@mail.gmail.com>
	<20100114130154.M2191@lyngbjerggaardskolen.dk>
Message-ID: <20100114131101.M53377@lyngbjerggaardskolen.dk>

From: "Gunner Poulsen" <gp at lyngbjerggaardskolen.dk>
To: Bert Van Vreckem <bert.vanvreckem at gmail.com>
Sent: Thu, 14 Jan 2010 14:10:03 +0100
Subject: Re: [Udpcast] Problem with Hitachi hard disk in 20091230 and posible
before

I tested that i could mount the hard disc in a Ubuntu live CD. I can, but I
don't have the courage to make a new cd.
I think it uses the libata module, but it doesn't work.

Gunner

On Thu, 14 Jan 2010 13:50:59 +0100, Bert Van Vreckem wrote
> Dear Gunner,
> 
> I had exactly the same problem with 42 shiny new Dell boxes that 
> spent their first months as very expensive paper weights...
> 
> In the end, I took a Linux kernel from a standard Fedora 
> installation and put it into a Udpcast CD boot image using the image 
> creator [http://udpcast.linux.lu/mkimagedoc.html]. To know which (S)
> ATA drivers you need exactly, boot Linux from a live cd and do an 
> lsmod in a terminal. In my case, it was pata_ahci and ata_generic 
> (IIRC). The busybox shell is no longer functioning on my new boot 
> cd&#39;s, but at least I can clone again...
> 
> Held og lykke. Let me know how it went and whether I can be of 
> further assistance...
> 
> bert
> 
> 2010/1/14 Gunner Poulsen <gp at lyngbjerggaardskolen.dk>
> Dear friends
> I use UDP-cast in my work as administrator on a school. It has worked
> brilliant for years :-)
> Now we have got 35 new labtops that I have to clone. But UDP-Cast 
> can&#39;t find the harddisk :-( The hard discs are: ATA Hitachi hts542525k9sa00
> UDP-cast just comes up with OTHER as harddisk partions to clone.
> Can anyone help?
> I beleve it is a fault in the driver.
> 
> Med venlig hilsen Gunner Poulsen
> Lærer på http://www.lyngbjerggaardskolen.dk
> Mobil: 30 24 58 72
> 
> _______________________________________________
> Udpcast mailing list
> Udpcast at udpcast.linux.lu
> https://udpcast.linux.lu/cgi-bin/mailman/listinfo/udpcast

Med venlig hilsen Gunner Poulsen
Lærer på http://www.lyngbjerggaardskolen.dk
Mobil: 30 24 58 72
------- End of Forwarded Message -------


Med venlig hilsen Gunner Poulsen
Lærer på http://www.lyngbjerggaardskolen.dk
Mobil: 30 24 58 72



From bert.vanvreckem at gmail.com  Thu Jan 14 14:24:20 2010
From: bert.vanvreckem at gmail.com (Bert Van Vreckem)
Date: Thu, 14 Jan 2010 14:24:20 +0100
Subject: [Udpcast] Problem with Hitachi hard disk in 20091230 and
	posible before
In-Reply-To: <20100114130154.M2191@lyngbjerggaardskolen.dk>
References: <20100114120711.M88508@lyngbjerggaardskolen.dk> 
	<b8248e301001140450m3b058394wd80d0b7268aa9921@mail.gmail.com> 
	<20100114130154.M2191@lyngbjerggaardskolen.dk>
Message-ID: <b8248e301001140524p72582a58sad8326a0505dfa03@mail.gmail.com>

Gunner,

I know the feeling.

When I posted about my problem, Alain Knauf suggested the following:

<<
In the "Cho[o]se hard disk controller module" menu, cho[o]se OTHER, and then
you get proposed a larger menu
>>

Maybe the driver you need is in the extended list. If not, then a custom
image is the only solution that I see. The complete command that I used was:

/usr/lib/udpcast/makeImage -c udpcd.iso -k /boot/vmlinuz -m "e1000e
ata_generic pata_acpi" -C udpcd.cfg --fullbox

The image generator is not so hard to install.

Cheers,

bert

2010/1/14 Gunner Poulsen <gp at lyngbjerggaardskolen.dk>

> I tested that i could mount the hard disc in a Ubuntu live CD. I can, but I
> don't have the courage to make a new cd.
> I think it uses the libata module, but it doesn't work.
>
> Gunner
>
> On Thu, 14 Jan 2010 13:50:59 +0100, Bert Van Vreckem wrote
> > Dear Gunner,
> >
> > I had exactly the same problem with 42 shiny new Dell boxes that
> > spent their first months as very expensive paper weights...
> >
> > In the end, I took a Linux kernel from a standard Fedora
> > installation and put it into a Udpcast CD boot image using the image
> > creator [http://udpcast.linux.lu/mkimagedoc.html]. To know which (S)
> > ATA drivers you need exactly, boot Linux from a live cd and do an
> > lsmod in a terminal. In my case, it was pata_ahci and ata_generic
> > (IIRC). The busybox shell is no longer functioning on my new boot
> > cd&#39;s, but at least I can clone again...
> >
> > Held og lykke. Let me know how it went and whether I can be of
> > further assistance...
> >
> > bert
> >
> > 2010/1/14 Gunner Poulsen <gp at lyngbjerggaardskolen.dk>
> > Dear friends
> > I use UDP-cast in my work as administrator on a school. It has worked
> > brilliant for years :-)
> > Now we have got 35 new labtops that I have to clone. But UDP-Cast
> > can&#39;t find the harddisk :-( The hard discs are: ATA Hitachi
> hts542525k9sa00
> > UDP-cast just comes up with OTHER as harddisk partions to clone.
> > Can anyone help?
> > I beleve it is a fault in the driver.
> >
> > Med venlig hilsen Gunner Poulsen
> > Lærer på http://www.lyngbjerggaardskolen.dk
> > Mobil: 30 24 58 72
> >
> > _______________________________________________
> > Udpcast mailing list
> > Udpcast at udpcast.linux.lu
> > https://udpcast.linux.lu/cgi-bin/mailman/listinfo/udpcast
>
>
> Med venlig hilsen Gunner Poulsen
> Lærer på http://www.lyngbjerggaardskolen.dk
> Mobil: 30 24 58 72
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.udpcast.linux.lu/pipermail/udpcast/attachments/20100114/926f1507/attachment.html>

From tomc at bio.umass.edu  Thu Jan 14 15:49:31 2010
From: tomc at bio.umass.edu (Tom Carpenter)
Date: Thu, 14 Jan 2010 09:49:31 -0500
Subject: [Udpcast] Problem with Hitachi hard disk in 20091230 and
 posible before
In-Reply-To: <20100114120711.M88508@lyngbjerggaardskolen.dk>
References: <20100114120711.M88508@lyngbjerggaardskolen.dk>
Message-ID: <4B4F2EFB.7090603@bio.umass.edu>

Assuming this is a SATA drive do you know if the laptops'
BIOS supports running the SATA controller in AHCI mode?
If you can enable that in the BIOS and use UDP Cast's AHCI
SATA driver are you then able to see the drive? If you weren't
aware of this, if you decide to configure the SATA controllers
to run in AHCI mode you may have to rebuild any disk images
that were originally prepared with the controllers set to
operate in IDE mode; as I understand it you'll run into
problems in Windows if you change the operating mode of the
controller after installation of the OS.

Gunner Poulsen wrote:
> Dear friends
> I use UDP-cast in my work as administrator on a school. It has worked
> brilliant for years :-)
> Now we have got 35 new labtops that I have to clone. But UDP-Cast can't find
> the harddisk :-(
> The hard discs are: ATA Hitachi hts542525k9sa00
> UDP-cast just comes up with OTHER as harddisk partions to clone.
> Can anyone help?
> I beleve it is a fault in the driver.
> 
> Med venlig hilsen Gunner Poulsen
> Lærer på http://www.lyngbjerggaardskolen.dk
> Mobil: 30 24 58 72
> 
> _______________________________________________
> Udpcast mailing list
> Udpcast at udpcast.linux.lu
> https://udpcast.linux.lu/cgi-bin/mailman/listinfo/udpcast
> 


-- 
Tom Carpenter


From gp at lyngbjerggaardskolen.dk  Tue Jan 19 02:33:32 2010
From: gp at lyngbjerggaardskolen.dk (Gunner Poulsen)
Date: Tue, 19 Jan 2010 02:33:32 +0100
Subject: [Udpcast] Problem with Hitachi hard disk in 20091230 and
	posible before
In-Reply-To: <4B4F1939.1932.4224B0@mikes.kuentos.guam.net>
References: <20100114120711.M88508@lyngbjerggaardskolen.dk>
	<4B4F1939.1932.4224B0@mikes.kuentos.guam.net>
Message-ID: <20100119012143.M73223@lyngbjerggaardskolen.dk>

Hmm. G4L actually works on the machines. 
I can start UDP-cast and it sees the hard disk.
But I will prefer to use UDP-cast alone because I start it from the server via
the bootpromp on the NIC.
So I beleve it is a bug in UDP-cast that it doesn't see the harddisk. Cant you
build in the controller cards as well Alain Knaff??

Gunner Poulsen

On Thu, 14 Jan 2010 23:16:41 +1000, Michael D. Setzer II wrote
> You might want to try my g4l program. It has a number of linux 
> kernels, and it includes udpcast. Can not be sure that it will see 
> the hard disks, but I build in most of the controller cards with the 
>  exception of experimental ones.
> 
> ftp://amd64gcc.dyndns.org/g4l-v0.32alpha46.iso
> 
> On 14 Jan 2010 at 13:24, Gunner Poulsen wrote:
> 
> From:           	"Gunner Poulsen" <gp at lyngbjerggaardskolen.dk>
> To:             	"UDPcast liste" <udpcast at udpcast.linux.lu>
> Date sent:      	Thu, 14 Jan 2010 13:24:12 +0100
> Subject:        	[Udpcast] Problem with Hitachi hard disk in 
> 20091230 and posible 	before
> 
> > Dear friends
> > I use UDP-cast in my work as administrator on a school. It has worked
> > brilliant for years :-)
> > Now we have got 35 new labtops that I have to clone. But UDP-Cast can't find
> > the harddisk :-(
> > The hard discs are: ATA Hitachi hts542525k9sa00
> > UDP-cast just comes up with OTHER as harddisk partions to clone.
> > Can anyone help?
> > I beleve it is a fault in the driver.
> >
> > Med venlig hilsen Gunner Poulsen
> > Lærer på http://www.lyngbjerggaardskolen.dk
> > Mobil: 30 24 58 72
> >


From tomc at bio.umass.edu  Tue Jan 19 19:45:38 2010
From: tomc at bio.umass.edu (Tom Carpenter)
Date: Tue, 19 Jan 2010 13:45:38 -0500
Subject: [Udpcast] "--full-duplex" option in cast-o-matic initrd images
Message-ID: <4B55FDD2.6050800@bio.umass.edu>

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


From breuer.jens at googlemail.com  Tue Jan 19 21:19:54 2010
From: breuer.jens at googlemail.com (Jens Breuer)
Date: Tue, 19 Jan 2010 21:19:54 +0100
Subject: [Udpcast] "--full-duplex" option in cast-o-matic initrd images
In-Reply-To: <4B55FDD2.6050800@bio.umass.edu>
References: <4B55FDD2.6050800@bio.umass.edu>
Message-ID: <76ce20421001191219v6b139bfcm9cd69bd68b544b38@mail.gmail.com>

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 at 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


From tomc at bio.umass.edu  Tue Jan 19 21:53:05 2010
From: tomc at bio.umass.edu (Tom Carpenter)
Date: Tue, 19 Jan 2010 15:53:05 -0500
Subject: [Udpcast] "--full-duplex" option in cast-o-matic initrd images
In-Reply-To: <76ce20421001191219v6b139bfcm9cd69bd68b544b38@mail.gmail.com>
References: <4B55FDD2.6050800@bio.umass.edu>
	<76ce20421001191219v6b139bfcm9cd69bd68b544b38@mail.gmail.com>
Message-ID: <4B561BB1.40501@bio.umass.edu>

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 at 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 at udpcast.linux.lu
> https://udpcast.linux.lu/cgi-bin/mailman/listinfo/udpcast
> 


-- 
Tom Carpenter
Computer Systems Specialist
Biology 347 Morrill
611 North Pleasant Street
Amherst, MA 01003-9297
phone: 413-577-2311
fax: 413-545-3243
email: tomc at bio.umass.edu


From breuer.jens at googlemail.com  Tue Jan 19 23:15:59 2010
From: breuer.jens at googlemail.com (Jens Breuer)
Date: Tue, 19 Jan 2010 23:15:59 +0100
Subject: [Udpcast] "--full-duplex" option in cast-o-matic initrd images
In-Reply-To: <4B561BB1.40501@bio.umass.edu>
References: <4B55FDD2.6050800@bio.umass.edu>
	<76ce20421001191219v6b139bfcm9cd69bd68b544b38@mail.gmail.com>
	<4B561BB1.40501@bio.umass.edu>
Message-ID: <76ce20421001191415n5a2cbd6du2a8873b9e8989238@mail.gmail.com>

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 at 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
>
> --------------------------------


From tomc at bio.umass.edu  Fri Jan 29 20:46:49 2010
From: tomc at bio.umass.edu (Tom Carpenter)
Date: Fri, 29 Jan 2010 14:46:49 -0500
Subject: [Udpcast] "--full-duplex" option in cast-o-matic initrd images
In-Reply-To: <76ce20421001191415n5a2cbd6du2a8873b9e8989238@mail.gmail.com>
References: <4B55FDD2.6050800@bio.umass.edu>	<76ce20421001191219v6b139bfcm9cd69bd68b544b38@mail.gmail.com>	<4B561BB1.40501@bio.umass.edu>
	<76ce20421001191415n5a2cbd6du2a8873b9e8989238@mail.gmail.com>
Message-ID: <4B633B29.80701@bio.umass.edu>

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 at 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 at udpcast.linux.lu
> https://udpcast.linux.lu/cgi-bin/mailman/listinfo/udpcast
> 


-- 
Tom Carpenter


From alain at knaff.lu  Sun Jan 31 00:30:59 2010
From: alain at knaff.lu (Alain Knaff)
Date: Sun, 31 Jan 2010 00:30:59 +0100
Subject: [Udpcast] "--full-duplex" option in cast-o-matic initrd images
In-Reply-To: <4B633B29.80701@bio.umass.edu>
References: <4B55FDD2.6050800@bio.umass.edu>	<76ce20421001191219v6b139bfcm9cd69bd68b544b38@mail.gmail.com>	<4B561BB1.40501@bio.umass.edu>	<76ce20421001191415n5a2cbd6du2a8873b9e8989238@mail.gmail.com>
	<4B633B29.80701@bio.umass.edu>
Message-ID: <4B64C133.9090506@knaff.lu>

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 at 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 at udpcast.linux.lu
>> https://udpcast.linux.lu/cgi-bin/mailman/listinfo/udpcast
>>
> 
> 



From tomc at bio.umass.edu  Sun Jan 31 05:17:31 2010
From: tomc at bio.umass.edu (Tom Carpenter)
Date: Sat, 30 Jan 2010 23:17:31 -0500
Subject: [Udpcast] "--full-duplex" option in cast-o-matic initrd images
In-Reply-To: <4B64C133.9090506@knaff.lu>
References: <4B55FDD2.6050800@bio.umass.edu>	<76ce20421001191219v6b139bfcm9cd69bd68b544b38@mail.gmail.com>	<4B561BB1.40501@bio.umass.edu>	<76ce20421001191415n5a2cbd6du2a8873b9e8989238@mail.gmail.com>
	<4B633B29.80701@bio.umass.edu> <4B64C133.9090506@knaff.lu>
Message-ID: <4B65045B.2060801@bio.umass.edu>

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


From alain at knaff.lu  Sun Jan 31 08:46:29 2010
From: alain at knaff.lu (Alain Knaff)
Date: Sun, 31 Jan 2010 08:46:29 +0100
Subject: [Udpcast] "--full-duplex" option in cast-o-matic initrd images
In-Reply-To: <4B65045B.2060801@bio.umass.edu>
References: <4B55FDD2.6050800@bio.umass.edu>	<76ce20421001191219v6b139bfcm9cd69bd68b544b38@mail.gmail.com>	<4B561BB1.40501@bio.umass.edu>	<76ce20421001191415n5a2cbd6du2a8873b9e8989238@mail.gmail.com>	<4B633B29.80701@bio.umass.edu>
	<4B64C133.9090506@knaff.lu> <4B65045B.2060801@bio.umass.edu>
Message-ID: <4B653555.6080008@knaff.lu>

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