A USB question.
I did some research and the on board NIC on my machine is not supported
by Linux (yet). I'm no coder, just a mere helpdesk lackey, so instead
of writing a driver for the NIC, I decided that maybe I'd try to run
UDPcast over USB. Now when I decompressed and mounted the initrd file,
there was one networking module that looked like it was a USB module,
but when I ran UDPcast from a bootable CD, I couldn't find that module
listed when I was asked to choose a network card. My questions then become:
- Can UDPcast run over USB without any modification to the bootable CD
image and does that include USB 1.0, 1.1 and 2.0?
- If so, how do I use it (what options must I choose)
--
Nate Sbar
Lab Support Supervisor
Phone: (703) 284-3854 or X3854
Pager: (703) 702-7065 or
7037027065(a)page.metrocall.com <mailto:7037027065@page.metrocall.com>
On Tue, 17 Dec 2002, Alain Knaff wrote:
> > I did so but it didn't help. What surprises me somewhat, is the fact
> > the the performance is also very low for only 1 sender and 1
> > receiver. Here's what I tried:
>
> Interesting...
>
> From your previous mail, I see that there are retransmissions starting
> at 1.41. It might be interesting to experiment with smaller slice
> sizes (i.e. less than 40 packets), and half-duplex. With these
> settings performance would still be bad (40 packets are far too few
> packets for half-duplex operation), but probably not as bad as it is
> now: Performance around 10 Mbps should be possible (due to small slice
> size, latency probably wouldn't allow to go faster than this).
>
> It might also be worthwhile experimenting with FEC. Performance around
> 40 Mbps (here, processing power of the CPU might be the limiting
> factor).
>
> Another thing to try is to use the --max-bitrate flag to limit how
> fast the sender sends. Try limiting to 500 Mbps, and check whether
> this makes it faster.... It is possible that for some strange reason,
> attempting to transmit at full speed might overflow some internal
> buffers on the switch, causing it to drop loads of packets, which
> makes the transmission slow due to retransmissions (but should it make
> the transmission _that_ slow?).
Thanks for your help, I was able to improve the Bitrate to
around 375 Mbps with the following commands:
Sender:
time ./udp-sender --file /dev/zero --half-duplex --interface eth1 --max-bitrate 500m
Receiver:
time ./udp-receiver --file /dev/null --interface eth1
I was able to maintain the performance up to 8 clients.
> And, knowing that the problem can be reproduced with just two
> computers, you might try to link the computers with a cross cable,
> rather than the switch. At least, that will allow us to tell whether
> it is a problem with the switch, or with udpcast.
Since the initial problem seems to be solved I did not try this.
- Felix
--
Felix Rauch | Email: rauch(a)inf.ethz.ch
Institute for Computer Systems | Homepage: http://www.cs.inf.ethz.ch/~rauch/
ETH Zentrum / RZ H18 | Phone: +41 1 632 7489
CH - 8092 Zuerich / Switzerland | Fax: +41 1 632 1307
I'm trying to make a bootable UDPcast CD and I really did RTFM. This is the problem I'm running into and I was hoping somebody out there could hold my hand.
I wanted to add a NIC driver to the list of drivers that UDPcast (specifically the Intel Pro/1000 MT) uses. The e1000.o file that I downloaded from Intel has the problem that it is too large to fit on the floppy boot disk (and yes, I did follow those instructions concerning the zipping and mounting of the initrd file).
Using the same theory and instructions, I decided that I might have a better go of it on a bootable CD where space is not yet an issue. First I just burned a CD without trying to modify it. I tested the CD and was pleasantly surprised to find that not only did the CD boot properly, but it seemed to have the Intel Pro/1000 drivers already installed. Unfortunately, those drivers couldn't detect my NIC, so I figured that the drivers were not recent enough to work on the particular iteration of the Intel 1000 NIC series in my machine.
Well, I went on the replacement binge. Downloaded the drivers from Intel, ran make to compile everything and get a nice little e1000.o driver file, followed the bootable floppy directions on the CD to extract and mount initrd, replaced the existing e1000.o file with the one I just downloaded and compiled, rearchived and renamed the file back to initrd (all caps like the original on the CD), copied the new initrd file to a zip disk, took the zip disk and the old CD to a windows machine (the only linux box on campus has no CD-R) copied the contents of the old CD to the windows hard drive minus the old initrd file, copied the new initrd file to the windows hard drive, and started burning.
After making several coasters, I found that I could not make any of these CD's bootable even though the CD burned just fine. I am using roxio 5 as my burning software and tried a few of the options to try to make a bootable CD. Just because I forgot to mention it before, yes I did change the boot sequence in the BIOS before trying to boot the CD. That's all the information I have right now. Can anybody tell me what I'm doing wrong. Please help a newbie justify the GPL in a very pro windows environment and thank you in advance for any help you can provide.
Nate Sbar.
Dear list members,
I'm interested in the best case performance of UDPcast on fast
networks like Fast Ethernet or Gigabit Ethernet. So far my results are
not so good, but maybe I'm doing something wrong and maybe somebody
can give me any hints.
For Fast Ethernet, I get the following performance (without disk
access):
Clients Performance [MB/s] re-xmits
1 11.8 12
2 0.89 142290
4 0.93 103320
8 1.0 ?
So, while I get wire speed with only one client and server, I only get
about 10% of the best performance for more than 1 client. Am I missing
something? Are the high re-xmit-numbers normal or do they point to a
problem? The commands I use are as follows:
node01:~/src/udpcast> ./udp-sender --file /dev/zero --full-duplex
node02:~/src/udpcast> ./udp-receiver --file /dev/null
On Gigabit Ethernet the performance seems even worse, I can barely
transmit any data. Here's what happens on the sender during 1 minute:
node01:~/src/udpcast> time ./udp-sender --file /dev/zero --full-duplex --interface eth1 --log /tmp/udpcast.log
Udp-sender 2001-12-31
172.25.1.101
Using mcast address 236.25.1.101
UDP sender for /dev/zero at 172.25.1.101
172.25.1.101 on eth1
Broadcasting control to 172.25.255.255
New connection from 172.25.1.102 (#0) 00000019
Ready. Press any key to start sending data.
Starting transfer: 00000019
bytes= 163 072 re-xmits=000000 ( 0.0%) slice=0112 - 0
Received retransmittal request for 1 from 0:
Retransmitting 1.41
Retransmitting 1.42
Retransmitting 1.43
Retransmitting 1.90
[CTRL-C]
0.000u 0.000s 1:06.53 0.0%mits=00+0k 0+0io 138pf+0we=0112 - 0
And on the receiver:
node02:~/src/udpcast> time ./udp-receiver --file /dev/null --interface eth1 --log /tmp/udpcast.log
Udp-receiver 2001-12-31
UDP receiver for /dev/null at 172.25.1.102
172.25.1.102 on eth1
received message, cap=00000019
Connected as #0 to 172.25.1.101
172.25.1.102
Listening to multicast on 236.25.1.101
Press any key to start receiving data!
bytes= 326 144 ( 0.29 Mbps)
Cancelled by user
0.000u 0.020s 1:15.49 0.0% 0+0k 0+0io 140pf+0w
Any ideas?
Regards,
Felix
--
Felix Rauch | Email: rauch(a)inf.ethz.ch
Institute for Computer Systems | Homepage: http://www.cs.inf.ethz.ch/~rauch/
ETH Zentrum / RZ H18 | Phone: +41 1 632 7489
CH - 8092 Zuerich / Switzerland | Fax: +41 1 632 1307
Hy, i'm trying to use UDPCast for installing 20 PC boxes in FineArts
Universiti at Barcelona, the problem I've found i think is no such
difficult to resolve, but I'm not able to. (head to short? :-) ).
Ok.lets go
1. Bootdisk failure in kernel booting:
enabled ExtINT on CPU 0
ESR value before enabling vector:00000000
ESR value after enabling vector:00000000
using local APIC timer interrupts
calibrating APIC timer
.... CPU clock speed is 1799.7757MHz
.... CPU hosts bus clock speed is 0.0000MHz
CPU:0, clocks:0, slice:0
------------kernel stops here ------------
bios technical specifications
BIOS PT84520A.86A.0010.P5 (for the sender) all machines have exactly
same HW conf. & same disk
Intel Celeron (R)
CPU 1.80 GHz
BUS 400 MHz
MEM 266 MHz
.
At this point I'm thinking to try and make a boot disk able to run on
this machinnes and then use udpcast for it.
Question? How I make this bootdisk?
the motherboards don't allowme turn off ACPI (i think its that the
problem) so I don't know anyway to get aout of it.
Thanks for any help
:)
oH!, my name is JACI or jazz. thnks
Le Mar 10 Déc 2002 23:45, vous avez écrit :
> > What do you mean by "server"? The sender, or just the DHCP server?
>
> The sender. The disk images will be stored on a machine one one subnet
> and all the receivers will be on another subnet.
ok
> > 1. If you mean the sender of data, you must be aware that multicast
> > works best within the same subnet. It is possible to get it to work in
> > different subnets by using the --ttl version on both the sender and
> > the receivers. This sets the "time to live" on the multicast packets,
> > allowing the to traverse routers. However, this only works if the
> > router supports multicast routing, but most unfortunately don't :-(
>
> Our router does support multicast, it is a Cisco 6500. I worked out the
> problem. The address range 224.0.0.0/24 is a reserved, non forwardable
> range. I had to chose and address outside this range for the routers to
> forward the packets. I used the address 239.0.0.1.
>
> I also came across some other problems. Sometimes, all the receivers
> timeout on the sender. I increased the timeout but that did not help.
> I think what is happening is the receiver misses a packet and sends a
> notification to the sender. That packet gets lost though and both
> sender and receiver are then left waiting for the other to make a move.
The udpcast server sends packets in batches ("slices") of up to 1024
packets. When a slice is transmitted, the sender "asks" the receivers
to send their confirmations. Receivers reply either with a
confirmation that everything has been received (good), or with a
bitmap of missing packets.
Missing packets are then transmitted, and confirmation is again asked
of those receivers which weren't ok the first time around.
If a receiver does not reply at all, the sender will re-ask for
confirmation every couple of seconds, until all confirmations are in.
If a receiver has not replied for about a minute, the sender drops
that receiver from its list, in order to be able to finish the
transmission with the others.
> If I limit the bit rate, this problem is less frequent so I think the
> router has bandwidth restrictions and once they are exceeded it drops
> packets. This would not be a problem though if the session did not
> timeout.
Unfortunately for the moment the timeout duration is hardwired, and is
200. This is specified in line 921 of senddata.c:
if(rexmitSlice->rxmitId > 200)
You can change it there to a higher value. In a future version, this
will become configurable.
> If this is the case, how hard do you think it would be for the receiver
> to retransmit whatever it needs to get the transmission going again, if
> say it has not got a reply from the sender in so many milliseconds?
>
> John.
Obviously, after a while, the router is dropping all the packets in
one direction (at least) after a while. After such an occurrence, no
matter what the receiver sends will not unblock the situation.
In order to debug this, you can try running the command-line variant
of udpcast on an server and (already installed) receiver(s), and run
tcdpump along with it to check where the packets are dropped.
Alain
is available at
Regarding my previous request (build failed on IA64) - once I have the
time I'll check out the relevant code section. If I'll deem that the
code is i386 specific (I'm no assembler expert) I'll explicitly drop
support of all other architectures from the debian source package.
*t
--
-----------------------------------------------------------
Tomas Pospisek
SourcePole - Linux & Open Source Solutions
http://sourcepole.ch
Elestastrasse 18, 7310 Bad Ragaz, Switzerland
Tel: +41 (81) 330 77 11
-----------------------------------------------------------
Hello Alan and ML,
I've packaged udpcast for Debian. And so the bugreports are starting to
flow in. Here's one. All udpcast bugs are archived at:
http://bugs.debian.org/udpcast
This particular one is archived at:
http://bugs.debian.org/172039
Can you comment on that?
*t
---------- Forwarded message ----------
Date: Fri, 06 Dec 2002 13:29:26 -0600
From: Bdale Garbee
Subject: Bug#172039: udpcast_20011231-4(unstable/ia64): FTBFS: i386
assembler inlines?
Resent-Date: Fri, 06 Dec 2002 19:33:11 GMT
Package: udpcast
Version: 20011231-4
Severity: important
This package fails to build from source on ia64, apparently because the FEC
algorithm is using some architecture-specific speedups?
Bdale
| Automatic build of udpcast_20011231-4 on caballero by sbuild/ia64 1.169
| Build started at 20021205-2244
[...]
| cc -O10 -Wall -c -o fifo.o fifo.c
| fifo.c: In function `initFifo':
| fifo.c:8: warning: cast from pointer to integer of different size
| cc -O10 -Wall -c -o log.o log.c
| log.c: In function `fatal':
| log.c:55: warning: implicit declaration of function `_exit'
| log.c:64: warning: implicit declaration of function `exit'
| cc -O10 -Wall -c -o statistics.o statistics.c
| gcc -c -O10 -Wall -fno-inline fec.c
| fec.c: In function `addmul1':
| fec.c:392: unknown register name `edx' in `asm'
| fec.c:392: unknown register name `eax' in `asm'
| fec.c: In function `mul1':
| fec.c:519: unknown register name `edx' in `asm'
| fec.c:519: unknown register name `eax' in `asm'
| fec.c: In function `addmul1':
| fec.c:392: inconsistent operand constraints in an `asm'
| fec.c: In function `mul1':
| fec.c:519: inconsistent operand constraints in an `asm'
| make[1]: *** [fec.o] Error 1
[...]
A complete build log can be found at
http://buildd.debian.org/build.php?arch=ia64&pkg=udpcast&ver=20011231-4