I meant to say, "the same recursive directory transfer *using scp" *... sorry!
On Tue, Dec 30, 2008 at 3:48 PM, Adam Bazinet <[email protected]>wrote: > > > On Tue, Dec 30, 2008 at 2:27 PM, John Bresnahan <[email protected]>wrote: > >> The retries is already set to 10, correct? But the docs say this is for >>> a >>> 'non-fatal' error. The problem is that when this error occurs, the >>> client >>> processes seem to be "hung" -- there is seemingly nothing happening. Is >>> there another way to specify re-tries with the rft command line client? >>> Something analogous to the <maxAttempts> field in RSL? >>> >> >> In 4.2 every error should be considered nonfatal, so retries will happen. >> 10 may not be a high enough value, can you look in the server logs to see >> if this error is tripped many times? >> >> > > I assume you mean the gridftp log, which I had to turn on (hopefully the > error log will suffice) > > Now I'm waiting for the error to happen again. > > One other question, in the meantime. Why is RFT so slow? The same > recursive directory transfer between hosts takes all of 3 or 4 seconds, and > with RFT each one takes several minutes- a huge difference. It's always > been this way, and I've just accepted it- but never thought to ask why. > > thanks, > Adam > > > > >> >> >> As you can see, one comes from 4.2.1, one from 4.2.0. Would upgrading >>> valine to 4.2.1 help, if you think this is a GridFTP server issue? It >>> sounded like you weren't so sure using globus-crft would help, although I >>> will see about using it anyway. >>> >> >> since this appears to be a server side issue there is no reason other than >> dumb luck that globus-crft would help. However, globus-crft tends to be a >> better tool in general so i recommend using it. >> > >
