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
Hello,
Here is my scenario. Clients A and B can succesfully be cloned from a
server running udp-sender when connected together via a hub. Either one can
also be successfully cloned as the only client to the server when connected
on the switch (as I understand it, this scenario is actually unicast, not
multicast).
When attemping to clone clients A and B on the switch simultaneously,
Client A writes:
----------
udpreceiver for /dev/hda2 at 10.90.0.172 on eth0
received message cap=00000019
connected as #0 to 10.90.0.167
listening to multicast on 234.90.0.167
----------
and then writes nothing else. Client B is similar.
The server writes numerous lines like this:
-------------
Timeout notAnswered=[1] notReady[1] nrAns=0 nrRead=0 nrPart=1 avg=65625
-------------
After what seems like a couple of minutes, the clients drop off and then the
server stops.
We are using a class B subnet which initially gave me problems, but after
specifying the broadcast address on the DHCP server I can confirm the
clients and server are all using a bcast address of 10.90.255.255
We are using a 3Com 4226T switch and in the list archives I see several
references to problems with 3Com switches and IGMP. I have disabled IGMP
querying and snooping, and disabled broadcast storm control. Flow control
can be specified per port - so for the 3 ports that these machines are
connected to, I've disabled flow control, disabled auto-negotiate, and set
to 100Mbps full duplex. (There are other active ports in use on the switch
and I've left those on auto-negotiate with flow control.)
Does anyone have some advice?
Thanks for your time,
Andrew Cameron
Systems Administrator
Vermont Legal Aid, Inc.
Hi,
Maybe this is interesting to those who just want to clone used blocks data.
The opensource project "Clonezilla" uses udpcast, partimage and DRBL. It
will let you multicast clone used blocks data to client machines. For
our case, we have 41 clients, the sample M$ Windows XP image size 4.5GB.
The average multicast cloning speed could be 0.8 GBytes/min to 1.3
GBytes/min. This make us finish cloning 41 clients in around 10 minutes.
The websites are:
http://clonezilla.sf.nethttp://drbl.sf.nethttp://drbl.nchc.org.tw
ps.
The Clonezilla server:
Intel(R) Pentium(R) 4 CPU 2.80GHz, 1 GB RAM, 2 2-port Intel e1000 NIC.
Client:
Intel(R) Pentium(R) 4 CPU 2.80GHz, 512 MB RAM, 1 on-board Intel e100 NIC
Switch:
2 DLink DES-1026G -24-Port 10/100-T + 2-Port 10/100/1000-T modules.
--
Steven Shiau
