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
I've managed to get reliable transfers to all 85 machines at this point
(bad nic in the sender, I think).
I'm still bottlenecking at 45Mbit or so, though, despite the fact that
all machines are on switched copper gigabit.
If fec is turned on (either 8x8/128 or 16x4/128), receivers disconnect
throughout the transfer until only ~10 remain at the end.
If fec is turned off, I get high retransmission rates (15-25%), but the
transfer at least succeeds to all hosts. Again, I'm sending about 20G of
data, which should take about an hour at 45Mbit. In practice, it takes
about an hour and a half, and sometimes close to two hours.
For simple point-to-point tests with udpcast (between 1 and 5
receivers), I can achieve higher bandwidths reliably (sending 128
megabytes at 80mbit), both with and without fec.
It sounds like my issue is similar to Ramon Bastiaan's:
http://lll.lgl.lu/pipermail/udpcast/2004-September/000298.html
Ramon, have you had any luck?
I am having problems booting any one of the cd and floppy images. The kernel
starts booting up to the stage where it issues the following prompts:
VFS: Mounted root (romfs filesystem) readonly.
Mounted devfs on /dev
Freeing unused kernel memory: 84k freed
After this the boot process hangs. I used the same cd/floppy to boot another
machine and it worked fine.
I have recompiled the kernel and made a new image with only the modules that I
need enabled and also tried using a monolithic kernel, all to no avail. I
also tried reducing the ramdisk size to 32000, but that also didn't work.
Using an image generated with the udpcast image generator and supplying all
the configuration parameters also didn't work.
The specs of the machine are:
VGA controller: S3 Inc. Trio64V2
Ethernet controller: Intel 82557
Chipset: PIIX4
NIC: eepro100
RAM: 64MB
CPU: Pentium MMX
I am kind of stumped what could be going wrong ...
Hi all,
I don't know if this should be applied to the source tree, but perhaps
some people will find this patch useful (I know we do).
We wanted some additional logging from udpcast to debug our casting
sessions, because it seems that the only thing logged to its logfile is
messages like this:
"Doubling slice size to 1024"
We also prefer syslog in stead of the separate file for logging
So I wrote this little patch.
It logs more information (very usefull for udpcast's running in the
background on a image server) and it logs it to syslog.
Information being logged:
* New connections
* Why a cast starts (is min clients reached or max wait passed, etc)
* Transfer start (+ what file,pipe,port,if,participants)
* Transfer complete
* Disconnects
See attached .patch
Kind regards,
--
Ramon Bastiaans
SARA - Academic Computing Services
Kruislaan 415
1098 SJ Amsterdam
Hi!
I'am using udpcast to transfert disk Images from a server to several clients.
The server box has one Network card and several virtual interfaces (eth0, eth0:0, eth0:1...).
When I try to send a file to one client through one of the virtual interface(eth0:x) everything goes well.
But when the client number increases (more than one) I get an error saying:
Rogue packet received <eth0 IP address>:9001 expecting <eth0:x IP address>:9001
The command line used on the server is :
udp-sender --file <filename> --interface eth0:x
On the client:
udp-receiver --file <filename>
It seems that only the eth0 interface can be used bay udpcast. It works perfectly with this one.
How can I get udpcast to work with my virtual interfaces
Sorry for my bad English!
Thank you for your help.
regards
Alex
On Wednesday 10 November 2004 10:42, Stephane wrote:
> Hi,
>
> I've unsuccessfully tried to send a message to the list.
> (I receive list's mail).
>
> I'm trying to solve the problem, contacting mailman...
> But I would like to send you my post to see if you can help me:
> ******************************************************************
> I would like to add precustomized images to a multiboot CD using isolinux.
In that case, you need to instruct makeImage to give you the initrd
(-i flag), rather than a finished cd or floppy image:
/usr/lib/udpcast/makeImage -i initrd -k /boot/vmlinuz-2.6.10udpcast
Then you store that initrd and the corresponding kernel on the CD, and
add the following paragraph to your isolinux.cfg file:
default linux
label linux
kernel vmlinuz
append root=01:00 initrd=initrd
(assuming that the initrd is still called initrd, and the kernel
vmlinuz)
Note: for 2.6 kernels, you need root=01:00, whereas for 2.4 kernels,
you need root=/dev/ram0
> I would like to only have one image and send parameters through the 'label'
> line in isolinux.cfg
The label line is not acessible to the kernel, this is only for the
boot loader's (Lilo, Grub, Syslinux) own usage (typically used as menu
headers)
However, you can add a limited amount of parameters to the append
line:
default linux
label linux
kernel vmlinuz
append root=01:00 initrd=initrd umode=rcv auto=yes
This passes the parameter umode=recv and auto=yes to udpcast, so it
won't ask whether it should behave as a receiver or as a sender.
Unfortunately, there is a limitation in the kernel, which limits you
to 6 such parameters, if I remember correctly.
> It would be nicer than customizing one image for each config.
But what you can do is put those parameters that are not likely to
change between each config into the initrd, and only leave those that
change on the kernel command line, in order not to overflow the
parameter count.
Regards,
Alain
hello group
i work for a school system and have been using UDPCast for a couple of years
now with great results. but we just got in the new dell gx280 pcs. they have
sata hard drivers and a broadcom gigabit ethernet card. i can not get the boot
disk nor the cd to use either device. is there anyone who has add these
devices to the /dev/ on the floppy or cd image?
(John Allison )
First let me thank you for udpcast, it has been a valuable tool for my
school district. And now to what I'm here for, we have gotten a new batch
of computers from Gateway with Marvell nic cards not supported with the
current version of udpcast. I have attempted to build a custom iso with
these new drivers following the instructions on the website. I used the
2.4.26 kernel sources and the rpm's from the site. I can't get the
computers to boot to determine if the new drivers work. I'm sure I've just
overlooked some small detail but I haven't been able to determine what.
I downloaded the linux driver from the Marvell site; installed in 2.4.26
src tree and built kernel according to instructions on the site.
I created the iso with the following command:
./makeImage -k
/usr/local/lx/2.4.26-udpcast/linux-2.4.26/arch/i386/boot/bzImage -c
udpcast1.iso --fullbox
the resulting iso is then burned to cd and when booted gives the following
error:
Please append a correct "root=" boot option.
kernel panic not able to mount root
Thanks,
Michael
--
Michael Williams Haywood County Schools
Technology Director Instructional Technology
http://www.haywood.k12.nc.us (828) 627-8314
Udpcast 20050206 is now released.
It has the following new features:
* Ramon Bastiaans' syslog patch
* SATA and SCSI support (for 2.6 kernels. There still is a module
loading issue with this when running on a 2.4 kernel)
* Improved layout of the embedded filesystem: formerly, a writable
tmpdir was mounted over /lib in order to allow write access to the
modules. However, this mounting also shadowed user-added shared
libraries. The new version mounts over /lib/modules, leaving
everything that is directly in /lib intact.
* Support network cards that have a PCI device class of 0x680 rather
than 0x200 (some nVidia cards do this...)
Bugfixes:
* Aliased interfaces (such as eth0:0) now work
* Fixed some race conditions which could happen at end of transfer
* Improved Cygwin compatibility
* Cleanup in keyboard handling
* Minor bugfixes in the makeImage script (bad test for symlinks, bad
ramdisk identifier for 2.6 kernels, ...)
External software upgrades:
* Upgraded to busybox-1.00
* Upgraded to kernels 2.6.10 and 2.4.29
Regards,
Alain
