Udpcast

udpcast@udpcast.linux.lu

556 discussions

UDPcast performance on high speed networks?
by Felix Rauch 17 Dec '02

17 Dec '02

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

3 3

problems with boot disk
by netman2＠seriousman.org 12 Dec '02

12 Dec '02

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

2 1

Re: udpcast
by Alain Knaff 11 Dec '02

11 Dec '02

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

1 0

udpcast Debian woody package
by Tomas Pospisek's Mailing Lists 10 Dec '02

10 Dec '02

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 -----------------------------------------------------------

2 4

Bug#172039: udpcast_20011231-4(unstable/ia64): FTBFS: i386 assembler inlines? (fwd)
by tomas pospisek 07 Dec '02

07 Dec '02

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

1 0

Udpcast mailing list
by Alain Knaff 30 Nov '02

30 Nov '02

The UDP cast mailing list is created!

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Udpcast