Thanks for your response, I think I encountered one of the "slow" machines
today while I was running some tests. I guess there are just some slow
ones in every group.
I met with some network analysts from my university today and they
explained how since the network is operating on a mixed CGMP/IGMPv2
environment multicasts are sometimes flaky. So, now that I may have found
a source of the problem my question is if any has any experience using
udpcast in a mixed environment, and if so what steps they took to make
udpcast more reliable. And also if there is a version of udpcast that uses
IGMPv2 rather than IGMPv3.
Thank you,
Mike
Hello everyone,
I recently started using udpcast and so far am very impressed. I am
however having a problem. When I try to udpcast to 5 clients, 1-3
typically give an error similar to the following:
Timeout notAnswered=[2,3,4] notReady=[2,3,4] nrAns=2 nrRead=2 nrPart=5
avg=10152
I've tried adjusting the transmission speed, multicast addresses, starting
the clients before the server or vise-versa. So far it appears to be
random which clients decide to "answer" and be "ready". Sometimes they all
work, sometimes 4 work, sometimes only 1 works, etc.
the lab I am working in is connected though a cisco 4006. From what I have
read cisco uses a proprietary IGMP implementation (called CGMP), could
this be a cause of some of the problems I am having?
If anyone has any insight into this problem please reply.
Thank you,
Mike
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
