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'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
Hello
At first nice Programm !!
My Prob is to insert tools in the initrd of udpcast image.
If i check it with chroot enviroment all seem ok.
But if I boot the precompiled Kernel an the initrd file, all inserted Programms already there.
I can ls or cat these files, but if I would run them the Error message File not found: is show.
Is this a problem with the busybox enviroment ? I don´t know ....check with chroot Env. is OK !!!
Any Ideas ??
Sorry for my bad english !
Hello Alain
First let me thanks you for this not enough known but great application (it
allows me to save a laptop hard drive where commercial product like Acronis
just fails and open source g4u didn't recognize the network card).
I'm considering using this product to save special configurations with PXE. I
successfully tested it with the linux24 precompiled kernel (the linux26 fails
to detect my USB keyboard). To avoid the menu options witch will be the same
accross my network I tried to use the documented keywords like those described
in http://www.udpcast.linux.lu/current/bootloader.html in the default file
after the append keyword( append initrd=initrd disk=/dev/hda umode=snd
auto=yes). I read a previous post that says that only the first 6 parameter are
taken into account. Here it just doesnt't work. Do you know if it's a kernel
configuration problem ? Is there a workaround (for example putting those
parameters in a another configuration file) to avoid the menus ?
A few words about an added feature I would like to have :
I would like to have several process waiting on my linux server ready to backup
several hosts in their owns "file.img". That implies at least two things :
The possibility to generate a unique file name for each different client (One
approach would be to send the mac address from the client and to use it with a
time stamp on the server).
The possibility for the receiver to be split in a daemon part that never quits
and a child process to be spawned for each client. For that part maybe it could
be easier to use in the middle an http server and a cgi script.
Do you think it's doable and what would be the difficulty to implement it ?
Thanks for your feedback.
Bernard.
Hiya..
Has anyone created an ISO image of UDPCast for an HP Proliant DL360?
These machines are becoming our "standard" Linux platform, and after we
have a "base" build, I would really like to be able to simply image that
base build to any subsequent machines we might build..
Thanks,
Richard.
--
Richard Whittaker, CISSP
System Manager,
NorthwesTel Inc.
Hi all,
I was wondering if anyone knows or could tell what the bottleneck is for
udpcast multicast speeds?
We have been using udpcast satisfactory for a while now in combination
with systemimager. In our previous situation the maximum speed seemed to
be around 20 Mbps (MAX_BITRATE). Setting the speed any higher would
result in dropped slices in the cast and some receivers not getting the
image in the first cast. This was on a 100 Mbps network.
We now have a new setup where we image machines over a 1000 Mbps
network, and the maximum speed seems to be 40 Mbps for udpcast? If we
cast any faster the number of machines failing to successfully receive
the cast dramatically increases (even though in the first tests, even at
40 Mbps there are 3 out of 40 still dropping).
Now this is on machines with 15.000 rpm scsi disk's. The hd and network
both should be able to go as fast as 100 MByte/sec in theory. However we
can't even get a stable cast at a 10th of this speed. It's not a very
big issue since we save a lot of time by imaging all machines at the
same time, but I was still wondering what exactly the bottleneck for the
multicast's speed is.
Is it the udp protocol, or the multicast technique, or could it still be
a hardware issue?
Any opinions on the subject are appreciated, perhaps some of the authors
of udpcast could give some insight?
Kind regards,
--
Ramon Bastiaans
SARA - Academic Computing Services
Kruislaan 415
1098 SJ Amsterdam
I tried casting /dev/zero to /dev/null on a node as you suggested
(thanks for the tip) and it seems there's nothing wrong with the
network:
-- on receiver --
Udp-receiver 2004-05-31
UDP receiver for /dev/null at 192.168.16.63 on eth0
received message, cap=00000019
Connected as #0 to 192.168.16.3
Listening to multicast on 232.168.16.3
Press any key to start receiving data!
Sending go signal 1 Success 0
bytes= 1 148 385 056 (913.38 Mbps)
Seems to be able to transfer up to 915 Mbps over our Gigabit, I would
love to get that speed! :)
BTW, When we tar, we don't use g/b zip on the tar, only tar itself.
I ran an other test, now with writing/reading to/from disk:
Udp-receiver 2004-05-31
UDP receiver for /tmp/cast.test/bla at 192.168.16.64 on eth0
received message, cap=00000019
Connected as #0 to 192.168.16.3
Listening to multicast on 232.168.16.3
Press any key to start receiving data!
bytes= 287 037 296 ( 57.35 Mbps) 286 969 856
Seems this is where it goes wrong. This is actually without any
compression.
I am going to try to figure out next why it slows down so dramatically
with the disk i/o. The disks should be able to go much faster than this,
it doesn't make any sense.
I've checked top on receiving clients, there's only about 3% cpu usage.
The error most of the receivers give when dropping out is:
"Dropped by server now=329 last=326" and different variations to this.
Regards,
Ramon.
> -----Original Message-----
> From: Alain Knaff [mailto:alain@knaff.lu]
> Sent: donderdag 23 september 2004 11:04
> To: Ramon Bastiaans
> Subject: Re: [Udpcast] what is the speed bottleneck?
>
> If you're running udpcast from a full system, try doing "top" to check
> CPU usage.
>
> If you compress, this could be an issue.
>
> If OTOH the speed is also slow in the /dev/zero->/dev/null scenario,
> you have confirmation that it is indeed a udpcact/network/switch
issue.
>
> Very wierd. Can you tell me which error message you get? What do you
> mean by "the last and now slice numbers"? Could you quote the exact
> message?
>
> Probably a different problem then....
>
> Please try doing the test without the tar. Also, what exact switches
> do you use for tar? Do you compress (-z)? Do you bzip (-j)?
>
> Also note that especially bzip is taxing on the CPU. You shouldn't get
> any transmission errors though, only bad performance. Something is
> weird here.
>
> Alain
I need a little software development done. We are a small company with
a limited budget, but some of you may be interested in the project.
Software Modules
1)Video Selection and playback
Goal:
Develop or Modify existing open source, or free software in order to
display a menu of different video clips (4-10), with their short (a few
words) and “preview” (a longer description). The menu will also be able
to perform a few functions, such as loading 3rd party programs, but it
MUST return when that 3rd party program is finished.
Features:
The software should be able to accept keyboard commands, and the entire
application should be able to be controlled using less then 6 keys total.
When the system is booted, it most go directly to this video selection
program
The video selection program must be able to load other programs, but
when that other program has finished, it must revert right back to the
video selection program. This feature should be able to be turned on
and off.
The program should play a very brief introduction video upon startup.
OS Requirements:
Linux, it must run under Linux.
Hardware Requirements
Must be able to run under Via's EPIA VE5000 motherboard/cpu.
(http://www.viavpsd.com/product/epia_v_spec.jsp?motherboardId=141)
Design Guidelines:
The program should reside in its own hard drive partition. The OS will
be in another partition, and all video will be located in a 3rd and
separate partition.
The program should use video files which will be named:
1_a_video.mpg, 1_b_video.mpg, 1_c_video.mpg, 2_a_video.mpg, etc. Each
video series will have a configuration file associated with it
(1_video.cfg) which will store information about each video clip series.
The naming scheme for the files can be changed.
Configuration File Guidelines:
The configuration file must store the following information:
The names of all associated video files and their order of play.
The name of a picture file used in the menu
The brief, and full description of the video files contained for each
series of clips
End Users:
This will be used in a Kiosk environment, and the users must be unable
to exit out of the video selection program.
2)Motion detection and program activation
Goal:
Use existing open source, or free software (ie motion, or other) to
develop a program to recognize whether people have entered an enclosed area.
Features:
The software should be able to determine if at least one person has
entered an enclosed area.
Once it has determined that the person has entered the enclosed area, it
should activate a program.
It should check every 30 seconds or so to make sure at least one person
is still in the enclosed area.
If no people are detected, it should shut down the program it previously
activated.
OS Requirements:
Linux, it must run under Linux.
Hardware Requirements
Must be able to run under Via's EPIA VE5000 motherboard/cpu.
(http://www.viavpsd.com/product/epia_v_spec.jsp?motherboardId=141)
Design Guidelines:
The people will be sitting in predictable places. So one idea could be
to assume that certain markings will always be in an approximate area.
Lets say a big “X” would be painted on the wall, and if a person sat
there, they would cover the “X”. So the program could safely assume
that a person had entered the enclosed area and activate a program.
Environment:
This will be used in a Kiosk environment, and the users must be unable
to exit out of the program. This program should run in the background,
and should automatically restart if it crashes.
3)Update Program
Goal:
To update a program and video files, each of which are located on their
own hard drive partition, utilizing UDPCast (http://udpcast.linux.lu/)or
modifying another open source, or free program.
There will be 2 parts to the program: 1) A interface at the central
computer to control the entire system, and 2) a background program
running on all “remote computers” (see block diagram) that will can
receive commands to update all “PC”'s (see block diagram)
Features:
Completely overwrite existing hard drive partitions with new data.
The entire network of computers will need to be administered remotely,
and most importantly, securely over the internet.
Easy to use
OS Requirements:
Linux, it must run under Linux.
Hardware Requirements
Must be able to run under Via's EPIA VE5000 motherboard/cpu.
(http://www.viavpsd.com/product/epia_v_spec.jsp?motherboardId=141)
Design Guidelines:
The program should run in KDE and be very user friendly.
A GUI should allow the user to select which video files he wants to be
updated to the remotely networked computers
This program will be stored on a “central computer” (see block diagram)
Block Diagram: Heirarchy of network
(see attach)
Environment:
This will be used in the KDE desktop, by administrators. The system
will also run in the background (and start on bootup) on the remote
comptuters and be used to updated the PC's on their individual networks.
---------
This propsoal is not written in stone, and suggestions or changes are
welcome!
Please email me if you are interested and I can provide attachments.
--
Jeff Gladnick
SnoRhino Snowboard Footrests
http://www.SnoRhino.com
Office: (856) 269-9324 (Temporary Line)
Cell: (302) 584-1445
On Tuesday 21 September 2004 18:57, Jeff Gladnick wrote:
> Isn't there a way to tune the routers so that they are all on the same
> network?
Well, if the router "repeats", it would have to do so on a different channel,
or else you'd get interference...
Even analog ham-radio repeaters do this: they repeat between to different
frequencies, or else they'd jam their own input...
> > It might even be feasible to setup Wifi access points on the poles,
> > rather than inside the gondolas (which would remove the problems of
> > access points moving around: in that case, only the receivers move, but
> > not the APs). Potential problem: will they withstand the cold?
> >
> > Alain
>
> That was my other idea. Now that I am becoming more aware about the
> hopping issues, it might be the best way to go. It does provide several
> advantages, such as a non-battery source of power, and reduces the
> overall cost of the system. Weatherproofing them is tedious but should
> be doable. Operating temperature on the routers is unfortunately 32F (0
> C), which is nowhere close to what I need.
Indeed... And you would also need to protect against humidity (really
waterproof boxes... and then you'd still need to worry about condensation)
> I suppose i could put a
> heater inside of the little "box" or whatever.
That would be an idea.
> Also, did anyone on the list have any interest in my request for a bid
> or estimate for the update program?
>
> -jeff
Which request do you mean?
Alain
