Hi
How long is the timeout on the new release? I used the new CD image (I think it's 20030607, or 20030610) and I found that I have to restart the operation if any of the receiver machines stop receiving. "Stop receiving" includes reboots and "No space left on device" errors.
I know there was a timeout value that was sometimes too short and caused "Pipeline full" errors and consequent dropping of the clients, but I haven't had a chance to look at the source again.
Andrew
----------------------- Andrew Cooks TechTeam TechTeam -- "We make it work." Computer Science dept. University of Pretoria -----------------------
Stimulate your mellon for a change! Use Linux! - http://tlug.up.ac.za
"If 44,000 employees of Sun can work with StarOffice, and can exchange any document with their customers, there is no good argument not to do it" - Richard Seibt, CEO of Suse Linux
On Tuesday 17 June 2003 08:50, Andrew Cooks wrote:
Hi
How long is the timeout on the new release?
About three and a half minutes.
I used the new CD image (I think it's 20030607, or 20030610) and I found that I have to restart the operation if any of the receiver machines stop receiving. "Stop receiving" includes reboots and "No space left on device" errors.
No, you don't need to restart; you just need to be patient ;) In other words, if your transfer has already been going on for more than 3 1/2 minutes, you win time by just waiting...
Timeout is so long in order to guard against accidental dropping of receivers in case of temporary network slowness. We once had a 3com switch which would pause for 30 seconds every minute during a udpcast transfer, and introducing really _long_ timeouts was the only way to cope...
I know there was a timeout value that was sometimes too short and caused "Pipeline full" errors and consequent dropping of the clients, but I haven't had a chance to look at the source again.
Actually, "Pipeline full" warnings are only marginally related to sender->receiver timeouts. "Pipeline full" warnings are displayed by the receiver when flow control kicks in (mostly, because data is received faster from the network than can be written to the disk or to a decompressor). The main motivation of these warnings was to do performance analysis (to determine whether any sub-optimal performance was due to inefficiencies in the network protocol, or to local reasons). As this message was confusing to users, it is now disabled by default (you should only get it if you compile udpcast with the DEBUG flag).
Regards,
Alain
-
Alain Knaff -
Andrew Cooks