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