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