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 downloaded your CD image and it worked fine until I used it on a pc with a
USB keyboard. These PCs are in the lab I am trying the program on. Do I need
to compile my own image using my own kernal? I am using debian 3.1 and cannot
find the required files as specified by the -k switch.
Please, let me know what I need to do.
Thanks,
AJ
Hi,
sorry for the last mail, i have forgotten to get a ip from dhcp.
So my question is, what i musst enter to the console to get a ip from dhcp?
thx
--
Lust, ein paar Euro nebenbei zu verdienen? Ohne Kosten, ohne Risiko!
Satte Provisionen f�r GMX Partner: http://www.gmx.net/de/go/partner
Hi,
i have load a initrd from the udpcast online tool and
have tried to use wget, tftp and ftpget and by all tools
I get a timeout.
I have found that the busybox tftp client have a bug, but not
the other tools.
Who can me they more about this problem?
thx
--
Telefonieren Sie schon oder sparen Sie noch?
NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie
Hi,
i want to add some modules and scripts to my initrd.
At first I have decompressed the initrd with bzip2.
Then I want to mount ("mount -o loop ./initrd /mnt/initrd"),
but I get the Message that the Filesystem is missing and ext2 and ext3 don't
work?
What I have done wrong ???
thx
--
10 GB Mailbox, 100 FreeSMS/Monat http://www.gmx.net/de/go/topmail
+++ GMX - die erste Adresse f�r Mail, Message, More +++
Hi all,
I have been using udpcast to image machines succesfully for a while now.
Now we are expanding our infrastructure with more machines and extra
networks, which I would like to image with the same server.
This seems to work a little, except for the fact that it does not
complete correctly on the new network(card/interface).
The receiver seems to get allmost all data, but the udp-receiver seems
to 'hang' at the end.
The most frustrating part is the udp-sender that says "Transfer
complete, disconnecting".
When I try it in unicast and sniff the network I see the following on a
_succesfull_ image to networkcard X:
16:06:59.620836 IP 192.168.16.3.9033 > 192.168.17.140.9032: UDP, length:
1472
16:06:59.620841 IP 192.168.16.3.9033 > 192.168.17.140.9032: UDP, length:
1472
16:06:59.620846 IP 192.168.16.3.9033 > 192.168.17.140.9032: UDP, length:
1472
16:06:59.620851 IP 192.168.16.3.9033 > 192.168.17.140.9032: UDP, length:
1472
16:06:59.620856 IP 192.168.16.3.9033 > 192.168.17.140.9032: UDP, length: 144
16:06:59.621146 IP 192.168.17.140.9032 > 192.168.16.3.9033: UDP, length: 8
16:06:59.621198 IP 192.168.16.3.9033 > 192.168.17.140.9032: UDP, length: 144
16:06:59.621397 IP 192.168.17.140.9032 > 192.168.16.3.9033: UDP, length: 8
16:07:00.654842 IP 192.168.16.3.9033 > 192.168.19.255.9032: UDP, length: 28
16:07:01.146772 IP 192.168.17.140.9032 > 192.168.16.3.9033: UDP, length: 4
When I do the same (failing) image to networkcard Y:
15:27:13.413078 IP 192.168.144.2.9047 > 192.168.144.200.9046: UDP,
length: 1472
15:27:13.413084 IP 192.168.144.2.9047 > 192.168.144.200.9046: UDP,
length: 1472
15:27:13.413089 IP 192.168.144.2.9047 > 192.168.144.200.9046: UDP,
length: 1472
15:27:13.413095 IP 192.168.144.2.9047 > 192.168.144.200.9046: UDP,
length: 1472
15:27:13.481157 IP 192.168.144.2.9047 > 192.168.144.200.9046: UDP,
length: 144
And then nothing.
This is the last part of the imaging process, right up till it completes
at networkcard X, and just hangs on networkcard Y.
It seems to me the last few packets are missing and that's causing the hang.
Anyone experienced something like this before and/or has any pointers to
what might cause this?
I suspect a switch or similar device to block the last packets. I.e. a
rate limiting setting or something.
Kind regards,
- Ramon Bastiaans.
--
There are really only three types of people:
Those who make things happen,
those who watch things happen,
and those who say, "What happened?"
---
ing. R. Bastiaans
HPC - Systems Programmer
SARA - Computing and Networking Services
Kruislaan 415 PO Box 194613
1098 SJ Amsterdam 1090 GP Amsterdam
