Udpcast June 2004

udpcast@udpcast.linux.lu

3 participants
3 discussions

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

Reliability - MD5sum's don't match
by Matthew Cooke 19 Jun '04

19 Jun '04

Hi, I wonder if someone could help me. I have started testing the UDPreceive/udpsend programs for rolling out linux onto refurbished PC's for a charity I work for. The idea is to role out linux onto 10-20 refurbished PC's (at once) before shipping them to charities/schools/colleges that really need them, mainly in Africa. I am using the command line version because we are not transfering a raw disk image we are transferring a tar'd tree and preparing the machines for custom hardware detection (as all the hardware is basically random). The tar file is about 1.2gig, and I am piping the output through both md5sum and tar to extract it. When I tried this on 1 machine everything was fine but today I tested it onto 5 machines in parallel and the MD5sum of the result on all 5 clients did not match the server version (they did however match each other) and the tar file appears to be slightly corrupted (though the machines did boot ok). So my question is "is it possible that the data is corrupted during multicasting?" and if so "Is there anything I can do to make it work reliably?" There seem to be quite a few error correction parameters available, which ones should I try first? Any help much appreciated, Matt.

2 1

RE: [Udpcast] udp-sender does not wait at all?
by Ramon Bastiaans 02 Jun '04

02 Jun '04

At first I was, but when I couldn't get the multicast senders to wait for the clients I tried manually running udp-sender and receiver. This to take flamethrower out of the equation and to pinpoint what was causing it. However, I already found the bug, and made a patch for it this morning. The problem is the time struct udp-sender uses to store the time at which the first receiver connects is never initialized to 0, while a if statement later on assumes that the value is 0 if no receiver has connected yet. This causes the udp-sender doesn't know the time of the first connected client and that it doesn't wait The fix is initializing the variable correctly and setting it to 0. I have attached a diff patch which corrects it, it works great now :) Regards, Ramon. > -----Original Message----- > From: Brian Elliott Finley [mailto:finley@mcs.anl.gov] > Sent: donderdag 27 mei 2004 17:46 > To: Ramon Bastiaans > Cc: udpcast(a)udpcast.linux.lu > Subject: Re: [Udpcast] udp-sender does not wait at all? > > Are you using flamethrower to do this? > > > Thus spake Ramon Bastiaans (bastiaans(a)sara.nl): > >Hi, > > > >I have been working on getting multicast systemimager image broadcasts > >to work, but I am having a hard time. > > > >Is it just me (am I doing something wrong?) or does udp-sender > >completely ignore the wait and client parameters? > > > >Udp-sender doesn't wait at all for a minimum number of clients, after > >the first connection, it immediately starts the multicast to the first > >client. > > > >On the server: > > > ># udp-sender --pipe 'tar -B -S -cpf - -C /home/test/sara/ramon/testdir . > >' --portbase 12345 --min-clients 20 --max-wait 1800 --min-wait 600 --fec > >8x8/128 --interface eth0 --max-bitrate 20M --full-duplex --nopointopoint > >--nokbd > >stripes=8 redund=8 stripesize=128 > >Udp-sender 2004-02-22 > >Using mcast address 234.168.44.1 > >Compressed UDP sender for (stdin) at 10.168.44.1 on eth0 > >Broadcasting control to 10.168.44.255 > >New connection from 10.168.44.5 (#0) 00000019 > >Starting transfer: 00000019 > >bytes= 11 929 600 re-xmits=000000 ( 0.0%) slice=1024 73 709 551 > >615 - 0 > >Transfer complete. > >Disconnecting #0 (10.168.44.5) > > > >On the client: > > > ># udp-receiver --interface eth0 --portbase 12345 --nokbd --nosync --file > >./bla.tar > >Udp-receiver 2004-02-22 > >UDP receiver for ./bla.tar at 10.168.44.5 on eth0 > >received message, cap=00000019 > >Connected as #0 to 10.168.44.1 > >Listening to multicast on 234.168.44.1 > >bytes= 11 929 600 ( 15.91 Mbps) 11 929 600 > >Transfer complete. > >ramon@u5:~/1.udptest$ > > > > > >Now there is no timestamps, but the udp-sender starts the multicast in > >about 2 seconds after the connect from the client. But the sender does > >not have 20 clients connected, and it didn't wait 10 minutes at all (I > >kind of overdid the values here, but with lower values it doesn't work > >either). > > > >Am I missing something? > > > >Kind regards, > > > >Ramon Bastiaans. > > > >_______________________________________________ > >Udpcast mailing list > >Udpcast(a)udpcast.linux.lu > >http://udpcast.linux.lu/mailman/listinfo/udpcast > > > > -- > ------------------------------------------------------ > Brian Elliott Finley Argonne, MCS Division > Mobile: 630.631.6621 Office: 630.252.4742 > gpg --keyserver wwwkeys.pgp.net --recv-keys 10F8EE52 > ------------------------------------------------------

3 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Udpcast June 2004