Hi Alain,
I was studying the UDPCast source code for some experimental purposes. I have the following question.
1. The whole data to be transfered into is divided into slices which again contains a series of blocks to transfer. Can we consider the whole data to be transfered as a single slice ( By setting appropriate parameters in code) and what kind of performance issues we can expect if we do a change of this kind at code level.
Thanks in advance,
Sai
---------------------------------
Do you Yahoo!?
Y! Messenger - Communicate in real time. Download now.
The option of ipappend 1 in the default file and retransmission
of HELLOs in udp-sender (--rexmit-hello-interval) has been
valuable to getting udpcast working with the Dell notebooks
we have with Broadcom 5700 series ethernet.
Today, with a slightly newer broadcom chipset appearing in
the most recent shipment, we noticed that udp-receiver was
intermittantly not showing the "hit any button to start transfer"
message. With some trial and error I found that if I
watched the tail of /var/log/message on the receiver (server)
and waited for the messages on TX and RX flow control to
complete before running udp-receiver, it would always initiate
a good connection. If I had started the udp-receiver
prior to the TX/RX flow control appearing in the message log
(in which case there was no "hit any key" message),
I could ^C the receiver, run it again and it would signify
the ready state with 100% success.
In conclusion, we have a workaround of starting udp-receiver
after a few seconds past the client PXE machine booting and
showing the udp-sender status ready (but not yet "hit any key...").
Another solution would be if udp-receiver also supported
--rexmit-hello-interval. It isn't a flaw in the udpcast system
but a kludge for a network device that is proving itself to be
sluggish in initialization in general.
--Donald Teed
Hi,
I don't know why, but I get more success in clonig using a class C mask
(255.255.255.0) than using a class B mask (255.255.0.0).
I would like to change the default mask to a class C one, but
the /bin/udpc_dialog isn't a text file.
Is it possible to change the default mask?
How should I do it?
Thank you very much.
--
Stephane Boireau
Personne Ressource TICE du Collège Le Hameau à Bernay (27)
PS:
'hope you'll understand the froggy way I write english;o).
Hello!
First of all, thanks for this extremely useful tool.
We use it to copy hd-images to a pool of 48 PCs, and it works
surprisingly well. At least, last semester it did :).
We use PXE to boot all clients into a small debian-system with r/o
nfs-roots, and cluster-ssh to control them all at once (eg., start
udp-receiver). Network is 100mbit half-duplex, the switch can handle
102gbit internally. Unfortunately, we have no physical access to the
switch.
On the server, we use this command to cast the complete harddisk:
cat /dev/hda | lzop -c - | udp-sender --half-duplex --max-bitrate 90m
On the clients, the opposite is:
udp-receiver | lzop -d - | dd of=/dev/hda
hda has about 29gb of used data, and a capacity of 80Gb. We do about 16
clients at the same time, and the first round went very well (it took
about 105 minutes to write the whole disk).
Now, the problem for the second 16 (which are the same hardware than the
first 16) is, that the speed of udpcast has dropped down from about
50mbit/s (with which it transferred about 24Gb) to right now about
50kbit/s (with which it has transferred about 5gb yet) (that's ok for
now, as they can finish writing the image over the easter-weekend), with
many timeoutnotanswered-messages on the sender.
These messages came from all clients every few seconds when the speed
was about 50mbit/s, but the client number 2 was overrepresented there
and the speed dropped down to about 50kbit/s, so I cut it off.
When udpcast reduces the speed to that of the slowest receiver, and that
receiver gets cut off, would it be possible that the speed gets up
again? At the moment it doesn't seem so ...
Thanks in advance, Lukas
Hi everybody i used the online tool cast-o-matic to create a receiver
floppy. I pre-configurated every option to make life easyer to our
users but it doesent seem to work... i mean it boots but it asks again
to configure every option.
Mounting the floppy i see a udpcfg.txt file containing the options i
selected online but...
Am i missing something?
--
Matteo
I've been modifying G4L (Ghost for Linux), which creates image
files, and I've got it working well. I am now looking at adding the
udpcast option to do the one to many option.
The g4l currently makes an image file to an ftp server basically
using dd -> compress (gzip, bzip, or lzop) -> ncftp - file.
The reversion is basically used to restore the image.
doing 1 restore takes about 50 minutes, and 2 takes a little over an
hour. Doing 19 machines at the same time takes about 6 1/2 hours.
The Udpcast can copy one machine to 19 machines in about 1 hour,
but it basically requires resetting a machine using the g4l first before
then coping that machine. I would like to be able to copy directly
from the image file to the machines.
Currently, I've been using lzop compression, since it gives the best
speed/size ratio. I've been able to use the udp-sender and udp-
receiver to copy the file from the one machine with the ftp server to
the other. But in trying to process the file thru the pipe, it doesn't do
what I expect.
The ideal is to transfer the compressed lzop file thru the udp, and
then have it be decompressed and run thru dd.
udp-receiver --pipe 'lzop -d -c - | dd of=/dev/hda'
Ideally, I'd like to have eight image files for the 8 labs in my building,
so any lab could be restored.
Thanks.
Note: my modified versions of g4l are on my college ftp server
ftp://202.128.73.29
+----------------------------------------------------------+
Michael D. Setzer II - Computer Science Instructor
Guam Community College Computer Center
mailto:mikes@kuentos.guam.net
mailto:msetzerii@gmail.com
http://www.guam.net/home/mikes
Guam - Where America's Day Begins
+----------------------------------------------------------+
http://setiathome.berkeley.edu
Number of Seti Units Returned: 15,758
Processing time: 30 years, 95 days, 14 hours, 11 minutes
(Total Hours: 265,094)
