 |
 |
As far as I understand, lcg-cp with more than 1 stream from external SE to a WN with NAT wouldn't work, right? And this is precisely what I have seen LHCB and ATLAS do - use lcg-cp with 4 and even 12 streams to download stuff. Which is quite fine with me. Are we saying that such behaviour is not supported? If a site is firewalled in such a way that it does not support such downloads, SFTs can detect the problem only if commands, that set the number of streams to be larger than 1, are included, correct? I got the impression that lcg-cp by default uses number of streams 1, while I would prefer the edg-rm default behaviour of making difference between large and small files. Emanouil Atanassov [log in to unmask] > > On Thu, 24 Mar 2005, Jeff Templon wrote: > > > Heh Heh, > > > > I'd forgotten all about Harold. I am getting ready to check my ETT code > > into CVS ... should I name the module Harold? > > > > J "LCG-ROLLOUT list server won't let me name it Stanley" T > > The rollout list server is able to constrain the names of CVS modules? > Anyway, SB may have a few more ideas for Harold's new function. > In the meantime H. is just lending a hand in naming LFNs, for example. > > > Maarten Litmaath wrote: > > > Jeff Templon wrote: > > > > > >> Hi, > > >> > > >> I am trying to debug a problem that Willem van Leeuwen intermittently > > >> sees: edg-rm cp fails with a 425 error "no route to host". It fails for > > >> example if he tries from a WN at SARA, but from a WN at some other > > >> places (e.g. Wuppertal) it works fine. I have verified the behavior in > > >> test jobs. > > >> > > >> I found the following information: > > >> > > >> https://savannah.cern.ch/bugs/?func=detailitem&item_id=2934 > > >> > > >> and > > >> > > >> http://goc.grid.sinica.edu.tw/gocwiki/425_425_Can't_open_data_connection%2e > > >> > > >> > > >> that seem to indicate a firewall is the problem, on the WN side. If the > > >> WN is firewalled (I assume a NAT system has the same effect) then there > > > > > > > > > Indeed: a firewall or NAT problem. > > > > > >> are several alternative actions that should be taken. One of them is to > > >> set the number of streams to 1 (one) for both large and small files. > > >> > > >> Funny thing is, both NIKHEF and SARA have the large-file transfers set > > >> to 3, so we (NIKHEF) should have this error too. And the SFT is not > > >> picking it up. I think it should, and I suspect the reason is that > > >> transfers are only done for small files, not large files. > > > > > > > > > Exact. We should add a test that downloads a 100 MB file. > > > > > >> Can we have a test put in to SFT for this behavior? And Willem, see the > > >> savannah link for a solution: use gbf for the third-party replication, > > >> and then edg-rm cp to get the file again. I hope this will work. The > > >> alternative is to set the number of streams to one on the command line, > > >> I hope this is still possible in LCG 2.3.1. > > > > > > > > > Yes: > > > > > > ----------------------------------------------------------------------- > > > $ edg-rm --vo dteam cr file:/etc/group -d lxb1767.cern.ch -l lfn:Harold > > > guid:8bcb69cd-233c-43bf-a4b6-c16c3307223a > > > $ edg-rm -v --vo dteam cp -n 1 lfn:Harold file:/tmp/nag > > > Running command : lcg-cp -v --vo dteam -n 1 lfn:Harold file:/tmp/nag > > > Source URL: lfn:Harold > > > File size: 671 > > > Source URL for copy: gsiftp://lxb1767.cern.ch/flatfiles/LCG-CERT-SE01/ > > > dteam/generated/2005-03-24/file913720aa-9bfa-4b71-90e4-33a34ba12b42 > > > Destination URL: file:/tmp/nag > > > # streams: 1 > > > Transfer took 690 ms > > > ----------------------------------------------------------------------- > > >