Udpcast May 2005

udpcast@udpcast.linux.lu

3 participants
4 discussions

UDPCast source code issues...
by Saikrishna Dasari 25 Apr '06

25 Apr '06

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.

3 2

Buggy tg3 ethernet
by Donald Teed 04 Apr '06

04 Apr '06

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

2 1

udpcast fails to multicast on 3Com switch
by Andrew Cameron 19 May '05

19 May '05

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.

2 1

udpcast + partimage + DRBL = Clonezilla
by Steven Shiau 06 May '05

06 May '05

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.net http://drbl.sf.net http://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

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Udpcast May 2005