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
> > > -----------------------------------------------------------------------
> >
>
|
