Re: [gt-user] GridFTP Troubleshooting

[Ian Foster]

Dear Amit:

Unfortunately I am not up to speed on the certificate issues. Things would be 
simpler if ATLAS used Globus -)

Regards — Ian

> On Aug 28, 2018, at 11:25 AM, Amit Kumar  wrote:
> 
> Hi Ian,
> 
> Thank you for quick response. Yes we have Globus connect server setup along 
> with an endpoint for our institution, and that works fine for us. This is a 
> new setup that I am working on so that I can get out LHC collaborators to use 
> GridFTP along for their ATLAS computing needs. 
> This (Globus connect) installation of GridFTP is a slightly different and 
> older works nicely for our DTN, but I need this new setup to use different 
> authentication (LCMAPS VOMS) hence working on another instance. 
> 
> I think I pretty close to getting this setup if I can figure out certificate 
> issues, seems basic to me but I lack a bit of understanding on this. Any 
> insight here will be a great help.
> 
> Thank you,
> Amit
> 
> On Tue, Aug 28, 2018 at 11:18 AM Foster, Ian T.  <mailto:fos...@anl.gov>> wrote:
> Dear Amit:
> 
> Have you tried installing Globus Connect and using the Globus transfer 
> service? Easier, faster, more reliable, …
> 
> See https://www.globus.org/data-transfer 
> <https://www.globus.org/data-transfer>
> 
> Regards — Ian
> 
>> On Aug 28, 2018, at 11:07 AM, Amit Kumar > <mailto:ihavebeenfor...@gmail.com>> wrote:
>> 
>> Dear GT,
>> 
>> I have setup GridFTP and trying to use globus-url-copy to test it and 
>> running it following errors, and wondering if you can help me here. 
>> 
>> I have a InCommon cert for the gridftp host, I also have InCommonRSAServerCA 
>> cert in the path but I am not able to find what issue certificate is it 
>> complaining about?
>> 
>> Any help here is greatly appreciated.
>> 
>> Thank you,
>> Amit
>> 
>> 
>> $ globus-url-copy -vb -dbg gsiftp://gftp.host.xxx.edu/tmp/zero.source 
>> <http://gftp.host.xxx.edu/tmp/zero.source> file:///tmp/zero.dest <>
>> Source: gsiftp://gftp.host.xxx.edu/tmp/ <http://gftp.host.xxx.edu/tmp/>
>> Dest:   file:///tmp/ <>
>>   zero.source  ->  zero.dest
>> debug: starting to get gsiftp://gftp.host.xxx.edu/tmp/zero.source 
>> <http://gftp.host.xxx.edu/tmp/zero.source>
>> debug: connecting to gsiftp://gftp.host.xxx.edu/tmp/zero.source 
>> <http://gftp.host.xxx.edu/tmp/zero.source>
>> 
>> debug: response from gsiftp://gftp.host.xxx.edu/tmp/zero.source 
>> <http://gftp.host.xxx.edu/tmp/zero.source>:
>> 220 10.10.29.20 GridFTP Server 12.8 (gcc64, 1531931206-85) [Globus Toolkit 
>> 6.0] ready.
>> 
>> debug: authenticating with gsiftp://gftp.host.xxx.edu/tmp/zero.source 
>> <http://gftp.host.xxx.edu/tmp/zero.source>
>> debug: fault on connection to gsiftp://gftp.host.xxx.edu/tmp/zero.source 
>> <http://gftp.host.xxx.edu/tmp/zero.source>: globus_ftp_control: 
>> gss_init_sec_context failed
>> debug: data callback, error globus_ftp_control: gss_init_sec_context failed, 
>> buffer 0x2aaab0ff3010, length 0, offset=0, eof=true
>> debug: operation complete
>> 
>> error: globus_ftp_control: gss_init_sec_context failed
>> OpenSSL Error: s3_clnt.c:1264: in library: SSL routines, function 
>> ssl3_get_server_certificate: certificate verify failed
>> globus_gsi_callback_module: Could not verify credential
>> globus_gsi_callback_module: Could not verify credential: unable to get 
>> issuer certificate
> 
> _
> Ian Foster
> Director, Data Science and Learning Division; Senior Scientist; Distinguished 
> Fellow, Argonne National Laboratory
> Arthur Holly Compton Distinguished Service Professor of Computer Science, 
> University of Chicago
> Fellow, Institute for Molecular Engineering
> Chief Troublemaker, Globus, www.globus.org <http://www.globus.org/> 
> Check out our new book: Cloud Computing for Science and Engineering
> Online at https://cloud4scieng.org <https://cloud4scieng.org/>
> Tel: +1 630 252 4619
> 
> 
> 
> 

[gt-user] Announcement regarding future support for open source Globus Toolkit

[Ian Foster]

[Below is also at 
https://github.com/globus/globus-toolkit/blob/globus_6_branch/support-changes.md
 
]

Support for open source Globus Toolkit will end as of January 2018; The Globus 
cloud service and Globus Connect are unaffected

The Globus team at the University of Chicago has developed and supported the 
open source Globus Toolkit  for close to 20 
years. Globus Toolkit GridFTP and GSI software, in particular, have been widely 
used within the scientific community for data transfer and security. Since 
2010, we have leveraged that experience to develop the Globus cloud service 
, which provides enhanced capabilities for data 
transfer plus new identity and group management, data sharing, data 
publication, and other functions. Most Globus Toolkit users have by now moved 
to the Globus cloud service and the associated Globus Connect endpoint 
software, used by tens of thousands of people to manage billions of files on 
more than 10,000 active endpoints. Importantly, a subscription-based 
sustainability model allows the Globus team to assure Globus cloud service 
users of our long-term viability.

We are announcing that, starting in January 2018, the Globus team at the 
University of Chicago will no longer support the open source Globus Toolkit, 
except for its use with the Globus cloud service by Globus subscribers. By the 
end of 2018, all endpoints connected to the Globus cloud service using the open 
source Globus Toolkit GridFTP server must migrate to Globus Connect. At the end 
of 2018, we will discontinue all maintenance (including security patches) and 
distribution of the open source Globus Toolkit. Endpoints using Globus Connect 
Server or Globus Connect Personal will be unaffected, as long as they continue 
to perform routine software updates.

We realize that this change in long-established practice may create challenges 
for those users who have not migrated to the Globus cloud service, and so we 
explain here first the reason for this change, and second, why we recommend 
that remaining Globus Toolkit users migrate to the Globus cloud service. Note 
that this change in support policy only affects direct users of the open source 
Globus Toolkit. Users of the Globus cloud service, and sites running Globus 
Connect to make their storage systems accessible via the Globus cloud service, 
are unaffected.

Why we are ceasing support of the open source Globus Toolkit. In a word, 
funding. The open source Globus Toolkit, like any software, requires constant 
effort to answer support requests, apply security patches, and perform other 
maintenance. This work has long been financed by grants, primarily from the 
U.S. National Science Foundation (NSF). However, our last such grant ends this 
fall and, after extensive discussions with funding agencies and Globus Toolkit 
users, we see little opportunity for further funding for such support 
activities.

In addition, Globus Connect is quickly diverging from the Globus Toolkit, as 
detailed in the FAQ. We must focus on supporting the Globus Connect code base, 
as this is what our subscribers depend on. Supporting and maintaining the open 
source Globus Toolkit would involve substantial, separate effort, for which 
no-one has shown a willingness to provide funding.

Why we recommend that current Globus Toolkit users migrate to, and subscribe 
to, the Globus cloud service. The Globus cloud service provides more 
functionality than the open source Globus Toolkit, is adding new capabilities 
rapidly, and is underpinned by a proven, sustainable business model that will 
ensure that it persists into the future. Subscribers get high-quality support 
from the Globus team, an assurance of software longevity, and the satisfaction 
of supporting a professional team that develops and operates valuable software 
for the research community. They also get access to capabilities that are 
superior to those provided by the open source Globus Toolkit: for example, 
automatic performance optimization, data sharing, specialized storage 
connectors (e.g., Google Drive, Amazon S3, Ceph, Spectra Logic BlackPearl), 
data publication, improved security, REST APIs, and powerful management 
services. The functionality gap between Globus Toolkit and the Globus cloud 
service will grow even larger as we develop more modern capabilities to support 
the research data management lifecycle, such as more storage connectors, 
web-compatible HTTPS+OAuth2 access to storage, metadata handling, data search 
with access control, and HIPAA compliance. Subscribers are collectively 
investing in, and helping us develop, these capabilities for the benefit of the 
broader research community.

Please contact us with any comments, questions, or concerns, at 
supp...@globus.org .

 

Re: [gt-user] upgrade GT4 to GT6

[Ian Foster]

Dear Monica:

Thanks for your enquiry. For various reasons (availability of funding, 
technical challenges with Web Services technologies), we have moved away from 
the Web Services foundation that underpinned GT4. We focus now on delivering 
research data management functions via software-as-a-service mechanisms: our 
Globus transfer service is a primary example. We also continue to support and 
enhance the non-Web Services elements of GT4 (GridFTP and GRAM in particular). 
However, we no longer have the capacity to support the Web Services components 
of GT4. 

If you are interested in the latest in Globus, I encourage you to attend 
GlobusWorld next April: http://globusworld.org <http://globusworld.org/>. 

Regards — Ian.

> On Oct 23, 2014, at 1:21 PM, monica zhu  wrote:
> 
> Hello everyone:
> 
> My name is Monica Zhu and I am a part-time grid developer at the Laboratory 
> of Molecular Evolution in University of Maryland. Our lab has been using GT4 
> for web-based grid developing for a long time, and we have build all of our 
> base services on GT4. With the update of GT5 and GT6, it seems like the 
> web-based packages in GT4 are not supported in the new GT versions. I was 
> wondering functions as RFT, MDS, RLS, and other ws functionalities will still 
> be a part of GT6. If not, is there any alternative ways to continue using 
> these functions in GT6. Thank you so much for your time! Hope you have a 
> great day!
> 
> Best,
> Monica Zhu

_
Ian Foster, ianfoster.org 
Computation Institute, www.compinst.org <http://www.compinst.org/> 
Math and Computer Science Division, Argonne Natl Lab
Dept of Computer Science, University of Chicago

Re: [gt-user] GridFTP DCSC transfer using different source and destination certs

[Ian Foster]

Should this be in our FAQ?

On Dec 4, 2013, at 3:53 PM, Stuart Martin  wrote:

> Hi All,
> 
> This was an off-list thread that may be helpful or informative to others, so 
> I am posting it here.
> 
> Scott's use case from his original email is:
> "Specifically, I am trying to transfer from Stampede to Blue Waters, using a 
> community account certificate to authenticate to Stampede and my user cert to 
> Blue Waters."
> 
> -Stu
> 
> Begin forwarded message:
> 
>> From: Scott Callaghan 
>> Subject: RE: Using different source and destination certs
>> Date: December 4, 2013 3:19:16 PM CST
>> To: Michael Link , Stuart Martin 
>> 
>> Hi Mike,
>> 
>> That worked!  I used my user cert as -data-cred since both ends can handle 
>> that one.  Thanks for your help!
>> 
>> -Scott
>> 
>> From: Michael Link 
>> Sent: Wednesday, December 4, 2013 3:10 PM
>> To: Scott Callaghan; Stuart Martin
>> Subject: Re: Using different source and destination certs
>> 
>> Ah, sorry about that, auto may have been added in 5.0.5 or 5.2.x.  You
>> can use either your src or dst cred for -data-cred as well -- it should
>> be packaged in a way that both servers can accept it.
>> 
>> Mike
>> 
>> On 12/4/2013 2:39 PM, Scott Callaghan wrote:
>>> Hi Mike,
>>> 
>>> I tried that, but it seems like -data-cred is expecting a file as an 
>>> argument:
>>> 
>>> globus-url-copy -data-cred auto -dbg -vb -src-cred /tmp/x509up_u801878 
>>> -dst-cred /tmp/x509up_u33527 
>>> gsiftp://gridftp.stampede.tacc.utexas.edu/home1/00940/tera3d/test.txt 
>>> gsiftp://bw-gridftp.ncsa.illinois.edu/u/sciteam/scottcal/test.txt
>>> Error loading data channel credential: GSS Major Status: General failure
>>> globus_gsi_gssapi: Unable to read credential for import: Couldn't open the 
>>> file: auto
>>> 
>>> I'm running guc version 5.14, as part of GT 5.0.4, in case it's a version 
>>> issue.  Thanks for your help with this!
>>> 
>>> -Scott
>>> 
>>> From: Michael Link 
>>> Sent: Wednesday, December 4, 2013 2:21 PM
>>> To: Scott Callaghan; Stuart Martin
>>> Subject: Re: Using different source and destination certs
>>> 
>>> Hi Scott,
>>> 
>>> I thought using both -src-cred and -dst-cred would automatically use
>>> DCSC, but you can force by adding '-data-cred auto'
>>> 
>>> Mike
>>> 
>>> On 12/4/2013 2:10 PM, Scott Callaghan wrote:
 Hi Stu,
 
 I used the command:
 
 globus-url-copy -dbg -vb -src-cred /tmp/x509up_u801878 -dst-cred 
 /tmp/x509up_u33527 
 gsiftp://gridftp.stampede.tacc.utexas.edu/home1/00940/tera3d/test.txt 
 gsiftp://bw-gridftp.ncsa.illinois.edu/u/sciteam/scottcal/test.txt
 
 /tmp/x509up_u801878 is the community account proxy, /tmp/x509up_u33527 is 
 the scottcal proxy.
 
 -Scott
 
 From: Stuart Martin 
 Sent: Wednesday, December 4, 2013 2:05 PM
 To: Scott Callaghan; Mike Link
 Cc: Stuart Martin
 Subject: Re: Using different source and destination certs
 
 Hey Scott,
 
 You should be able to do this with guc.  Can you reply with the specific 
 options you are using on the guc command?  Here are the relevant options 
 to use.
  -cred 
  -src-cred | -sc 
  -dst-cred | -dc 
 Set the credentials to use for source, destination,
 or both ftp connections.
  -data-cred 
 Set the credential to use for data connection.  A value of 'auto' will
 generate a temporary self-signed credential.  This may be used with
 any authentication method, but the server must support the DCSC 
 command.
 
 Also, Globus Transfer would do this for you after you activate each 
 endpoint with the credential.  So, you could let Globus do the work for 
 you :-)
 
 including Mike for any additional followup.
 
 Cheers,
 Stu
 
 On Dec 4, 2013, at Dec 4, 1:18 PM, Scott Callaghan  
 wrote:
 
> Hi Stu,
> 
> Good to see you at SC.
> 
> I tried out using different certificates to authenticate to the source 
> and destination, using a third-party transfer.  It looks like the 
> authentication goes fine, but then, as I understand it, both hosts also 
> have to be able to authenticate to the other certificate, and I think 
> that's where things are failing.
> 
> Specifically, I am trying to transfer from Stampede to Blue Waters, using 
> a community account certificate to authenticate to Stampede and my user 
> cert to Blue Waters.  It looks like Stampede is able to authenticate both 
> certificates, but Blue Waters has an issue with the community account 
> cert.  I get the error:
> 
> debug: response from 
> gsiftp://bw-gridftp.ncsa.illinois.edu/u/sciteam/scottcal/test.txt:
> 500-Command failed. : callback failed.
> 500-OpenSSL Error: s3_srvr.c:2985: in library: SSL routines, function 
> SSL3_G

Re: [gt-user] Globus Toolkit with Pidora 18 - ARM6

[Ian Foster]

Dear Fabio:

Thanks for letting us know.

Regards -- Ian.

On Oct 8, 2013, at 8:02 AM, Fabio Moreira  wrote:

> Dear Ian,
> 
> I've decided to install Fedora Remix instead of Pidora. With Remix I could 
> install all necessary packages to build a GridFTP server with Raspberry.
> 
> Best Regards
> 
> 
> On Mon, Oct 7, 2013 at 7:44 PM, Ian Foster  wrote:
> Fábio:
> 
> Did you get this working?
> 
> Regards -- Ian
> 
> On Aug 8, 2013, at 3:18 PM, Fábio Moreira  wrote:
> 
> > Hi,
> >
> > I would like to use Globus Toolkit with a raspberry-arm6 and I've installed 
> > pidora 18. Although many Globus package has already been compiled from 
> > Fedora to Pidora, some packages, globus-gridftp-server and myproxy for 
> > instance, are missing.
> >
> > Can anyone help me?
> >
> > Thanks in advance,
> >
> > Fabio MS
> 
> 
> Fábio MS

Re: [gt-user] Globus Toolkit with Pidora 18 - ARM6

[Ian Foster]

Fábio:

Did you get this working?

Regards -- Ian

On Aug 8, 2013, at 3:18 PM, Fábio Moreira  wrote:

> Hi,
> 
> I would like to use Globus Toolkit with a raspberry-arm6 and I've installed 
> pidora 18. Although many Globus package has already been compiled from Fedora 
> to Pidora, some packages, globus-gridftp-server and myproxy for instance, are 
> missing.
> 
> Can anyone help me?
> 
> Thanks in advance,
> 
> Fabio MS

Re: [gt-user] license about Globus Toolkit

[Ian Foster]

Dear Antonio:

Globus Toolkit components are released under Apache v2. Strangely that 
information seems to have disappeared in a recent web site reorganization. 
We'll get that fixed.

Regards -- Ian.


On Aug 19, 2013, at 9:33 PM, Antonio Miguel Bonacin 
 wrote:

> Hello,
> 
> I want to know about the part of the Globus Toolkit license for installation 
> on RedHat.
> 
> I'll installer a grid computing using Globus Toolkit and I don't no about the 
> license of the product.
> 
> Thanks,
> 
>  
>  
> Att,
>  
> 
> Antonio Miguel Bonacin
> Consultoria
> +55 (11) 3853-1291
> +55 (11) 98564-8727
> www.tenbu.com.br
>  
> Antes de imprimir, pense na sua responsabilidade com o MEIO AMBIENTE.
> Esta mensagem, incluindo seus anexos, pode conter informações privilegiadas 
> e/ou de caráter confidencial. Se você não é o destinatário ou pessoa 
> autorizada a recebê-la, você não está autorizado a utilizar esse material 
> para qualquer fim. Se você recebeu esta mensagem por engano, por favor, nos 
> informe respondendo a este e-mail e apague-o.
>  
> Before printing, think about your responsibility toward the ENVIRONMENT
> This message (including its attachments) can be confidential and private. If 
> you are not authorized to receive it you are not allowed to use it for any 
> reason. If you received this by mistake, please contact-us by replying this 
> e-mail and erase it.
>  
>  
>  

Re: [gt-user] Data Replication Service

[Ian Foster]

Dear Walter:

I misread what you wanted to do: I gather that you want to distribute 30TB to N 
people, in such a way that the total download volume from your site is much 
less than 30*N. Thus you want some sort of peer-to-peer structure whereby early 
downloaders help to distribute the data to later downloaders. (Let me know if I 
have it wrong.) Globus Online doesn't provide direct support for that use case, 
at present. I suspect that BitTorrent is a good bet.

Regards -- Ian.


On Jun 16, 2013, at 12:05 AM, Walter Landry  wrote:

> Thanks.  It looks like the only solution that Globus Online offers for
> peer-to-peer requires buying a Globus Online Plus plan.  Even then, it
> sounds like it is still in Beta.
> 
> I will need to distribute about 30 TB of public domain data to anyone
> who wants it.  When doing data releases in the past, we have had
> problems with our dual GigE network getting saturated.  So just
> setting up an anonymous GridFTP server would probably not be an
> optimal solution.  Should I just use Bittorrent?  The Globus Online
> solution looks more oriented towards sharing private data with
> collaborators.
> 
> Thank you,
> Walter Landry
> 
> Ian Foster  wrote:
>> Dear Walter:
>> 
>> The right tool to use for Data Replication now is Globus Online, in my view. 
>> See www.globusonline.org. 
>> 
>> Ian.
>> 
>> On Jun 14, 2013, at 4:51 PM, Walter Landry  wrote:
>> 
>>> Hello,
>>> 
>>> I was wondering what the status of the Data Replication Service is.
>>> Is it still included with GT?  I can see documentation for it in GT
>>> 4.0, but I can not find it in the documentation for GT 5.2.4.
>>> 
>>> Thanks,
>>> Walter Landry
>> 

Re: [gt-user] Data Replication Service

[Ian Foster]

Dear Walter:

The right tool to use for Data Replication now is Globus Online, in my view. 
See www.globusonline.org. 

Ian.

On Jun 14, 2013, at 4:51 PM, Walter Landry  wrote:

> Hello,
> 
> I was wondering what the status of the Data Replication Service is.
> Is it still included with GT?  I can see documentation for it in GT
> 4.0, but I can not find it in the documentation for GT 5.2.4.
> 
> Thanks,
> Walter Landry

Re: [gt-user] Using globus-url-copy between ftp -> gsiftp

[Ian Foster]

Good. So did I :)

On Jun 7, 2013, at 1:37 PM, Brock Palen  wrote:

> Ian,
> 
> I put in a plug with the HMB project for the benefits of setting up anon 
> endpoints for their data.
> 
> Brock Palen
> www.umich.edu/~brockp
> CAEN Advanced Computing
> bro...@umich.edu
> (734)936-1985
> 
> 
> 
> On Jun 7, 2013, at 11:45 AM, Ian Foster  wrote:
> 
>> we should get as many people as possible to request this.
>> 
>> On Jun 7, 2013, at 10:37 AM, Brock Palen  wrote:
>> 
>>> Steve, 
>>> 
>>> We are consumers of data from a resource we don't have control over.  
>>> Getting that resource on Globus would be wonderful though,
>>> 
>>> It's the Human Microbiome Project.
>>> http://www.hmpdacc.org/resources/data_browser.php/
>>> 
>>> They provide public FTP and HTTP download, getting them in as a public data 
>>> source on GO would do the community a lot of good. 
>>> 
>>> 
>>> 
>>> Brock Palen
>>> www.umich.edu/~brockp
>>> CAEN Advanced Computing
>>> bro...@umich.edu
>>> (734)936-1985
>>> 
>>> 
>>> 
>>> On Jun 7, 2013, at 9:40 AM, Steve Tuecke  wrote:
>>> 
>>>> Is it possible to upgrade the FTP server to (anonymous) GridFTP? That 
>>>> should allow it to work with both globus-url-copy and Globus Online.
>>>> 
>>>> -Steve
>>>> 
>>>> On Jun 7, 2013, at 7:57 AM, Brock Palen  wrote:
>>>> 
>>>>> MIke thanks good to know that it only works with file:///  which kinda 
>>>>> defeats the point with what we are trying to do.
>>>>> 
>>>>> Thanks.
>>>>> 
>>>>> Brock Palen
>>>>> www.umich.edu/~brockp
>>>>> CAEN Advanced Computing
>>>>> bro...@umich.edu
>>>>> (734)936-1985
>>>>> 
>>>>> 
>>>>> 
>>>>> On Jun 7, 2013, at 2:17 AM, Michael Link  wrote:
>>>>> 
>>>>>> Hi Brock,
>>>>>> 
>>>>>> It is likely that those servers don't support third party transfers, or 
>>>>>> fxp as it is commonly called with standard ftp servers.  While some 
>>>>>> standard ftp server software supports this, it is often not enabled on 
>>>>>> public servers.
>>>>>> 
>>>>>> With the second server, it recognizes that the port you're telling it to 
>>>>>> connect to isn't the same one that the client is connecting from, and 
>>>>>> fails.
>>>>>> 
>>>>>> With the first I suspect it is simply ignoring the address portion of 
>>>>>> the PORT argument and attempting to connect to the client address.
>>>>>> 
>>>>>> Either should work if you're able to run globus-url-copy on the same 
>>>>>> host as the gridftp server, though that may of defeat the purpose.
>>>>>> 
>>>>>> Mike
>>>>>> 
>>>>>> On 6/4/2013 4:36 PM, Brock Palen wrote:
>>>>>>> I need to have a user push a lot of data though a host from an FTP only 
>>>>>>> site to our gridftp server.  The user has to do it this way because we 
>>>>>>> don't allow user login on this host  (sftp, and globusonline only)
>>>>>>> 
>>>>>>> Because we setup this host with GCMU we have self signed certs etc. but 
>>>>>>> I was able to manualy set subjects.  Problem is I can't get the 
>>>>>>> transfer to work:
>>>>>>> 
>>>>>>> globus-url-copy -dbg -v -ds '' 
>>>>>>> ftp://public-ftp.hmpdacc.org/Illumina/stool/SRS045004.tar.bz2 
>>>>>>> gsiftp://gridftp-flux.engin.umich.edu/scratch/support_flux/brockp/tmp/
>>>>>>> 
>>>>>>> Just hangs, and the file says size zero.
>>>>>>> 
>>>>>>> Last line of debug information is:
>>>>>>> debug: sending command to 
>>>>>>> ftp://public-ftp.hmpdacc.org/Illumina/stool/SRS045004.tar.bz2:
>>>>>>> PORT 141,212,30,14,196,207
>>>>>>> 
>>>>>>> I tried using another ftp server and I get a different error:
>>>>>>> 
>>>>>>> globus-url-copy  -dbg -v -ds '' 
>>>>>>> ftp://mirror.optus.net/fedora/linux/extras/README 
>>>>>>> gsiftp://gridftp-flux.engin.umich.edu/scratch/support_flux/brockp/tmp/
>>>>>>> 
>>>>>>> error: globus_ftp_client: the server responded with an error
>>>>>>> 500 Illegal PORT command
>>>>>>> 
>>>>>>> Any thoughts on why I can't do this?
>>>>>>> 
>>>>>>> Brock Palen
>>>>>>> www.umich.edu/~brockp
>>>>>>> CAEN Advanced Computing
>>>>>>> bro...@umich.edu
>>>>>>> (734)936-1985
>>>>>>> 
>>>>>>> 
>>>>> 
>>> 
>> 
> 

Re: [gt-user] Using globus-url-copy between ftp -> gsiftp

[Ian Foster]

we should get as many people as possible to request this.

On Jun 7, 2013, at 10:37 AM, Brock Palen  wrote:

> Steve, 
> 
> We are consumers of data from a resource we don't have control over.  Getting 
> that resource on Globus would be wonderful though,
> 
> It's the Human Microbiome Project.
> http://www.hmpdacc.org/resources/data_browser.php/
> 
> They provide public FTP and HTTP download, getting them in as a public data 
> source on GO would do the community a lot of good. 
> 
> 
> 
> Brock Palen
> www.umich.edu/~brockp
> CAEN Advanced Computing
> bro...@umich.edu
> (734)936-1985
> 
> 
> 
> On Jun 7, 2013, at 9:40 AM, Steve Tuecke  wrote:
> 
>> Is it possible to upgrade the FTP server to (anonymous) GridFTP? That should 
>> allow it to work with both globus-url-copy and Globus Online.
>> 
>> -Steve
>> 
>> On Jun 7, 2013, at 7:57 AM, Brock Palen  wrote:
>> 
>>> MIke thanks good to know that it only works with file:///  which kinda 
>>> defeats the point with what we are trying to do.
>>> 
>>> Thanks.
>>> 
>>> Brock Palen
>>> www.umich.edu/~brockp
>>> CAEN Advanced Computing
>>> bro...@umich.edu
>>> (734)936-1985
>>> 
>>> 
>>> 
>>> On Jun 7, 2013, at 2:17 AM, Michael Link  wrote:
>>> 
 Hi Brock,
 
 It is likely that those servers don't support third party transfers, or 
 fxp as it is commonly called with standard ftp servers.  While some 
 standard ftp server software supports this, it is often not enabled on 
 public servers.
 
 With the second server, it recognizes that the port you're telling it to 
 connect to isn't the same one that the client is connecting from, and 
 fails.
 
 With the first I suspect it is simply ignoring the address portion of the 
 PORT argument and attempting to connect to the client address.
 
 Either should work if you're able to run globus-url-copy on the same host 
 as the gridftp server, though that may of defeat the purpose.
 
 Mike
 
 On 6/4/2013 4:36 PM, Brock Palen wrote:
> I need to have a user push a lot of data though a host from an FTP only 
> site to our gridftp server.  The user has to do it this way because we 
> don't allow user login on this host  (sftp, and globusonline only)
> 
> Because we setup this host with GCMU we have self signed certs etc. but I 
> was able to manualy set subjects.  Problem is I can't get the transfer to 
> work:
> 
> globus-url-copy -dbg -v -ds '' 
> ftp://public-ftp.hmpdacc.org/Illumina/stool/SRS045004.tar.bz2 
> gsiftp://gridftp-flux.engin.umich.edu/scratch/support_flux/brockp/tmp/
> 
> Just hangs, and the file says size zero.
> 
> Last line of debug information is:
> debug: sending command to 
> ftp://public-ftp.hmpdacc.org/Illumina/stool/SRS045004.tar.bz2:
> PORT 141,212,30,14,196,207
> 
> I tried using another ftp server and I get a different error:
> 
> globus-url-copy  -dbg -v -ds '' 
> ftp://mirror.optus.net/fedora/linux/extras/README 
> gsiftp://gridftp-flux.engin.umich.edu/scratch/support_flux/brockp/tmp/
> 
> error: globus_ftp_client: the server responded with an error
> 500 Illegal PORT command
> 
> Any thoughts on why I can't do this?
> 
> Brock Palen
> www.umich.edu/~brockp
> CAEN Advanced Computing
> bro...@umich.edu
> (734)936-1985
> 
> 
>>> 
> 

Re: [gt-user] How to distribute problems to multiple resources (computers)?

[Ian Foster]

Dear John:

GRAM5 is popular because:
-- It provides higher performance and reliability relative to Web 
Services-based systems
-- It is backwards compatible with the widely used GRAM2 sytem

Regards -- Ian. 


On Nov 21, 2012, at 5:09 AM, john...@hushmail.com wrote:

> It seems that GT5 users are too smart to need such a documentation. Or may be 
> that I should ask in the gt-dev instead (although I think this is more of a 
> gt-user sort of discussion).
> 
> Here is my understanding of how GT5 should be set-up:
> * a tool, outside of GT5's bundle, should be used to register the resources 
> in a directory service.
> * a tool, outside of GT5's bundle, should be used to query the directory 
> service above in order to obtain a list of suitable resources.
> * a tool, outside of GT5's bundle, should be used to execute 
> `globus-job-submit` command to the suitable available resources.
> * a tool, outside of GT5's bundle, should monitor the jobs.
> 
> Now, it seems to me that GT5 is only providing the following:
> * a file transfer (GridFTP).
> * a host-to-host job submission tool (GRAM).
> * an authentication mechanism (MyProxy).
> 
> Assuming that my above understanding is correct (I could be wrong), most of 
> the Grid functionality is provided by non-GT5 tools, and those that are 
> provided by GT5 are easily replaceable (e.g. GRAM can be replaced by a simple 
> wrapper or even a shell script). This makes me wonder what is the 
> significance of GT5? To me it seems the need is almost none (it is not 
> providing a partial implementation of the OGSA standard either. It seems that 
> GT5 eventually created yet another non-standard API to further extend the 
> lack of inter-operability mess that we had between grid platforms).
> 
> However, I could understand the significance of GT4.x.x as it provided many 
> more tools that facilitated a working Grid environment, and was aiming to 
> follow a standard (although partial).
> 
> Regards,
> J
> 
> On 11/19/2012 at 7:59 PM, john...@hushmail.com wrote:
> Is there any documentation that describes how to construct a complete grid 
> system using GT5?
> 
> On 11/19/2012 at 6:41 PM, "john alexander sanabria ordonez" 
>  wrote:
> Well, GRAM interfaces with local batch schedulers such as SGE, Condor, PBS 
> and so on. In that context, GRAM hides details concerning with the scheduler 
> where a job is submitted. Then, you have a pool of clusters and your duty is 
> only submit the task and don't really care about the job submission details.
> 
> GRAM also provides tools and services for monitoring job's status. 
> 
> There exists some meta-schedulers such as GridWay where, AFAIK, you submit 
> your job and it decides in which grid computing resources (aka. cluster) your 
> job should run.
> 
> John,
> 
> On 19 November 2012 09:14,  wrote:
> Interesting. I thought that's the main reason why anyone would need a grid 
> platform: to distribute problems to multiple computers. If GT5 is not doing 
> that, then what is it doing?
> 
> The quote below is from the documentation of GT5.2.2[1]:
> "The Grid Resource Allocation and Management (GRAM5) component is used to 
> locate, submit, monitor, and cancel jobs on Grid computing resources. GRAM5 
> is not a Local Resource Manager, but rather a set of services and clients for 
> communicating with a range of different batch/cluster job schedulers using a 
> common protocol. GRAM5 is meant to address a range of jobs where reliable 
> operation, stateful monitoring, credential management, and file staging are 
> important."
> 
> From my understanding, GRAM5 (part of GT5) aims at handling a range of jobs 
> (i.e. not a single job) + monitoring..etc. I assume that since it claims 
> handling a range of jobs, it should somehow figure out which nodes to 
> distribute at.
> 
> I think my expectations about GT5 are incorrect. Perhaps I am missing the key 
> objectives of GT5. Any clarifications would be appreciate it.
> 
> Regards, 
> J
> 
> On 11/19/2012 at 4:38 AM, "Steven C Timm"  wrote:
> The GT4 globus toolkit did include an implementation of the Monitoring and 
> Discovery Service, which can be used by a number of sites to advertise to 
> some central service which could then tell the user where to 
> globus-job-submit (or globusrun-ws –submit as GT4 did.)
> 
> In practice most production grids have some other non-globus method of 
> telling the user which sites are available and now many free
> 
> Slots that they have.  Most common one is the BDII.  The Open Science Grid in 
> the US uses that, but also uses software known
> 
> As the GlideinWMS to present the whole grid as a single unified resource to 
> users.
> 
>  
> Steve Timm
> 
>  
>  
> From: gt-user-boun...@lists.globus.org 
> [mailto:gt-user-boun...@lists.globus.org] On Behalf Of john...@hushmail.com
> Sent: Sunday, November 18, 2012 5:52 PM
> To: gt-user
> Subject: [gt-user] How to distribute problems to multiple resources 
> (computers)?
> 
>  
> Greetin

Re: [gt-user] How to distribute problems to multiple resources (computers)?

[Ian Foster]

Dear John:

GT is used for that purpose in large grid systems such as the Open Science 
Grid. GRAM provides uniform, secure, reliable job submission to a specific 
site, and for staging of data in and out. MDS provides for monitoring of site 
status. Various groups have used these components to implement so-called 
"meta-schedulers" that use site status information to determine where to submit 
jobs. See A Resource Management Architecture for Metacomputing Systems. K. 
Czajkowski, et al. Proc. IPPS/SPDP '98 Workshop on Job Scheduling Strategies 
for Parallel Processing, pg. 62-82, 1998 for the architectural approach.

You asked specifically about the rather specialized sub-problem of distributing 
work to a large and presumably time-varying pool of volunteer computers. One 
could do that with GT, but BOINC is really optimized for that specific problem.

Ian.


On Nov 19, 2012, at 8:14 AM, john...@hushmail.com wrote:

> Interesting. I thought that's the main reason why anyone would need a grid 
> platform: to distribute problems to multiple computers. If GT5 is not doing 
> that, then what is it doing?
> 
> The quote below is from the documentation of GT5.2.2[1]:
> "The Grid Resource Allocation and Management (GRAM5) component is used to 
> locate, submit, monitor, and cancel jobs on Grid computing resources. GRAM5 
> is not a Local Resource Manager, but rather a set of services and clients for 
> communicating with a range of different batch/cluster job schedulers using a 
> common protocol. GRAM5 is meant to address a range of jobs where reliable 
> operation, stateful monitoring, credential management, and file staging are 
> important."
> 
> From my understanding, GRAM5 (part of GT5) aims at handling a range of jobs 
> (i.e. not a single job) + monitoring..etc. I assume that since it claims 
> handling a range of jobs, it should somehow figure out which nodes to 
> distribute at.
> 
> I think my expectations about GT5 are incorrect. Perhaps I am missing the key 
> objectives of GT5. Any clarifications would be appreciate it.
> 
> Regards, 
> J
> 
> On 11/19/2012 at 4:38 AM, "Steven C Timm"  wrote:
> The GT4 globus toolkit did include an implementation of the Monitoring and 
> Discovery Service, which can be used by a number of sites to advertise to 
> some central service which could then tell the user where to 
> globus-job-submit (or globusrun-ws –submit as GT4 did.)
> 
> In practice most production grids have some other non-globus method of 
> telling the user which sites are available and now many free
> 
> Slots that they have.  Most common one is the BDII.  The Open Science Grid in 
> the US uses that, but also uses software known
> 
> As the GlideinWMS to present the whole grid as a single unified resource to 
> users.
> 
>  
> Steve Timm
> 
>  
>  
> From: gt-user-boun...@lists.globus.org 
> [mailto:gt-user-boun...@lists.globus.org] On Behalf Of john...@hushmail.com
> Sent: Sunday, November 18, 2012 5:52 PM
> To: gt-user
> Subject: [gt-user] How to distribute problems to multiple resources 
> (computers)?
> 
>  
> Greetings GT community,
> 
>  
> Suppose that a pool of computers are able to donate their idle CPU time, how 
> can a problem (i.e. an piece of code) get executed in them in a distributed 
> manner? 
> 
>  
> For example, when I use the command globus-job-submit, or globus-job-run, how 
> will my local machine know where should these jobs to be submitted?
> 
>  
> I'm expecting that every resource should register itself to a discovery data 
> base (service) that is hosted on a server(s). And that grid users (e.g. 
> programmers/researchers) submit problems, they submit it somewhere that will 
> dispatch them to multiple resources (CPU donators) according to a scheduler 
> and an execution management plan that decies what to do in case of a failure.
> 
>  
> However, I fail to see how the above thoughts map to GT5 after following my 
> reading of the quick start guide in 
> http://www.globus.org/toolkit/docs/5.2/5.2.2/admin/quickstart/ -- what is in 
> the guide is pretty controlled by the user/programmer (e.g. he specifies 
> which computer to execute which commands on).
> 
>  
> Rgrds,
> 
> J
> 

Re: [gt-user] How to distribute problems to multiple resources (computers)?

[Ian Foster]

I think that BOINC is what you are looking for. Or Condor.

On Nov 18, 2012, at 5:52 PM, john...@hushmail.com wrote:

> Greetings GT community,
> 
> Suppose that a pool of computers are able to donate their idle CPU time, how 
> can a problem (i.e. an piece of code) get executed in them in a distributed 
> manner? 
> 
> For example, when I use the command globus-job-submit, or globus-job-run, how 
> will my local machine know where should these jobs to be submitted?
> 
> I'm expecting that every resource should register itself to a discovery data 
> base (service) that is hosted on a server(s). And that grid users (e.g. 
> programmers/researchers) submit problems, they submit it somewhere that will 
> dispatch them to multiple resources (CPU donators) according to a scheduler 
> and an execution management plan that decies what to do in case of a failure.
> 
> However, I fail to see how the above thoughts map to GT5 after following my 
> reading of the quick start guide in 
> http://www.globus.org/toolkit/docs/5.2/5.2.2/admin/quickstart/ -- what is in 
> the guide is pretty controlled by the user/programmer (e.g. he specifies 
> which computer to execute which commands on).
> 
> Rgrds,
> J

Re: [gt-user] (no subject)

[Ian Foster]

I suggested Globus Online (and GCMU) not for performance, but to simplify 
installation.

On Oct 9, 2012, at 10:01 AM, "Sill, Alan"  wrote:

> You haven't mentioned the networking conditions under which you are 
> operating.  the transfer time that you mention would be equivalent to an 
> average transfer speed of 114 Mbytes/sec, or 912 Mbits/sec, for a 120 GByte 
> file, as implied by the name of the file you cite for the transfer.
> 
> That would be essentially full saturation of a 1 GbE line, for example.
> 
> The parallelism options of gridFTP (which are not part of the free globus 
> Online service, unless I am mistaken) would not help you exceed the maximum 
> transfer rate possible for your hardware, but might help, depending on 
> details of network topology, for longer-distance transfers in which you are 
> not otherwise able to hit network saturation.
> 
> Magic has not yet been invented, unfortunately (although the folks on the 
> Globus team are no doubt working on this!)
> 
> Alan
> 
> On Oct 9, 2012, at 9:47 AM, gridftp user 
> wrote:
> 
>> 
>>> Hi Melvin,
>>> I recommend that you install Globus Connect 
>> Multi-User - https://www.globusonline.org/gcmu/ and use Globus Online 
>> (www.globusonline.org) to do the transfer. 
>>> 
>>> In case of 
>> the transfer you mention below, if you add say '-p 4' or '-p 8' to the 
>> globus-url-copy command line, you should get much better transfer rate. 
>> That said, you should really be using Globus Online as it does 
>> autotuning of the parameters to get good performance. 
>>> 
>>> Raj
>> 
>> 
>> Hi Raj,
>> 
>> 
>> 
>> Thank you for taking the time to respond. Adding the -p switch made no real 
>> difference:
>> 
>>   time globus-url-copy -v -p 8 file:/opt/120_GB_file.random 
>> sshftp://172.22.10.206/home/test/bigfile.random
>> 
>> 
>> 
>>   real 17m34.074s
>> 
>>   user 0m3.116s
>> 
>>   sys 1m55.821s
>> 
>> 
>> I thought I must have managed to miss that in my reading, but that 
>> information is unfortunately missing
>> from all of the on-line documentation that I've read over the past week. In 
>> fact, even knowing what to look
>> for I am unable to find it mentioned in any site documentation at all. I did 
>> find it by typing globus-url-copy
>> -help, which gives me some reading that I've not gone through yet.
>> 
>> Any chance the lack of improvement is due to the fact that the traffic is 
>> going out one server, through a
>> single switch, and back into the receiving server? I ask because I am not a 
>> network engineer by any means
>> and I am trying to get an understanding of what is going on. If the 
>> infrastructure is an issue then an outside
>> test is in order.
>> 
>> I appreciate the suggestion of using Globus Online. We looked into that, but 
>> we do not want our
>> data residing on systems we do not control, even if it is there for a short 
>> time. That is why I am
>> trying so hard to set up a server/client system, so we can have almost 
>> complete control over both
>> end-points and transfer parameters.
>> 
>> I'll keep plugging away.
>> 
>> Melvin
>> 
>>
> 

Re: [gt-user] (no subject)

[Ian Foster]

Dear Melvin:

Note that Globus Online does NOT move your data to systems you do not control. 

Ian.

On Oct 9, 2012, at 9:47 AM, gridftp user  wrote:

> 
>> Hi Melvin,
>> I recommend that you install Globus Connect 
> Multi-User - https://www.globusonline.org/gcmu/ and use Globus Online 
> (www.globusonline.org) to do the transfer. 
>> 
>> In case of 
> the transfer you mention below, if you add say '-p 4' or '-p 8' to the 
> globus-url-copy command line, you should get much better transfer rate. 
> That said, you should really be using Globus Online as it does 
> autotuning of the parameters to get good performance. 
>> 
>> Raj
> 
> 
> Hi Raj,
> 
> 
> 
> Thank you for taking the time to respond. Adding the -p switch made no real 
> difference:
> 
>time globus-url-copy -v -p 8 file:/opt/120_GB_file.random 
> sshftp://172.22.10.206/home/test/bigfile.random
> 
> 
> 
>real 17m34.074s
> 
>user 0m3.116s
> 
>sys 1m55.821s
> 
> 
> I thought I must have managed to miss that in my reading, but that 
> information is unfortunately missing
> from all of the on-line documentation that I've read over the past week. In 
> fact, even knowing what to look
> for I am unable to find it mentioned in any site documentation at all. I did 
> find it by typing globus-url-copy
> -help, which gives me some reading that I've not gone through yet.
> 
> Any chance the lack of improvement is due to the fact that the traffic is 
> going out one server, through a
> single switch, and back into the receiving server? I ask because I am not a 
> network engineer by any means
> and I am trying to get an understanding of what is going on. If the 
> infrastructure is an issue then an outside
> test is in order.
> 
> I appreciate the suggestion of using Globus Online. We looked into that, but 
> we do not want our
> data residing on systems we do not control, even if it is there for a short 
> time. That is why I am
> trying so hard to set up a server/client system, so we can have almost 
> complete control over both
> end-points and transfer parameters.
> 
> I'll keep plugging away.
> 
> Melvin
> 
> 

[gt-user] Please help: Seeking information from GT users (by July 7 if possible)

[Ian Foster]

Dear friends:

Further to my email below, we have set up a Web survey to make it easier for 
you to provide this information. 

See: https://strategy.wufoo.com/forms/globus-toolkit-user-survey

It will be most helpful to us if you can reply by July 7.

Many thanks,

Ian.



On Jun 24, 2011, at 3:52 AM, Ian Foster wrote:

> Dear friends:
> 
> We are preparing a proposal to the National Science Foundation to provide 
> continued support for the Globus Toolkit (GT): specifically, for the GRAM, 
> GridFTP, Integrated Information Service, Grid Security Infrastructure, and 
> jGlobus components.
> 
> Our success will depend in part on our ability to get NSF researchers and 
> educators to communicate to their program managers the importance of this 
> technology for their work. In the absence of such communications, NSF will 
> conclude that Globus software isn't that important.
> 
> We know that there are many users out there. For example, just in the last 24 
> hours, GridFTP servers with usage reporting enabled reported 17M transfers, 
> totaling 0.5 PB (that's an average of 200 files/sec and 6 GB/sec). But we 
> need to know *who*, *what*, and *why* for this usage--and for the usage of 
> other components.
> 
> Thus, we would like to request your help as follows:
> 
> 1) If you an NSF-supported researcher or educator who uses GT in your work, 
> please:
> 
> a) tell us how and why it is important to you
> 
> b) tell us what improvements and enhancements will be most important to you
> 
> c) let us know if you are prepared to contact your NSF program manager to 
> tell them these things, and who that would be
> 
> Note: While we welcome detail and completeness, just a few words on these 
> topics will be immensely useful
> 
> 2) If you are a non-NSF-supported researcher or educator (in the US or 
> elsewhere) who uses GT in the work, please:
> 
> a) tell us how and why it is important to you
> 
> b) tell us what improvements and enhancements will be most important to you
> 
> c) tell us who supports your work
> 
> Regards -- Ian.
> 
> 
> 
> 
> 
> 

[gt-user] Please help: Seeking information from GT users

[Ian Foster]

Dear friends:

We are preparing a proposal to the National Science Foundation to provide 
continued support for the Globus Toolkit (GT): specifically, for the GRAM, 
GridFTP, Integrated Information Service, Grid Security Infrastructure, and 
jGlobus components.

Our success will depend in part on our ability to get NSF researchers and 
educators to communicate to their program managers the importance of this 
technology for their work. In the absence of such communications, NSF will 
conclude that Globus software isn't that important.

We know that there are many users out there. For example, just in the last 24 
hours, GridFTP servers with usage reporting enabled reported 17M transfers, 
totaling 0.5 PB (that's an average of 200 files/sec and 6 GB/sec). But we need 
to know *who*, *what*, and *why* for this usage--and for the usage of other 
components.

Thus, we would like to request your help as follows:

1) If you an NSF-supported researcher or educator who uses GT in your work, 
please:

a) tell us how and why it is important to you

b) tell us what improvements and enhancements will be most important to you

c) let us know if you are prepared to contact your NSF program manager to tell 
them these things, and who that would be

Note: While we welcome detail and completeness, just a few words on these 
topics will be immensely useful

2) If you are a non-NSF-supported researcher or educator (in the US or 
elsewhere) who uses GT in the work, please:

a) tell us how and why it is important to you

b) tell us what improvements and enhancements will be most important to you

c) tell us who supports your work

Regards -- Ian.

Re: [gt-user] GridFTP + UDT success for bio-mirror.net and code patches

[Ian Foster]

Dear Don:

Thank you very much for the detailed report.

We'll follow up separately on the code patches.

On the performance front: I know nothing about your configuration, but I can 
imagine that you might be able to do even better. Would you be interested in 
having us work with you on identifying the bottleneck(s)?

Regards -- Ian.


On Aug 13, 2010, at 1:04 PM, Don Gilbert wrote:

> 
> Dear Globus folks,
> (maybe this should go to -dev rather than -user)
> 
> We have been testing GridFTP + UDT (gt5.0.2) for the Bio-mirror.net  project,
> which daily mirrors 100's of GB of biology data around the world. The results
> so far are very good. There have been some installation problems, and
> I have code patches if you want them.  A few of these I think would be
> usefully added to a future GridFTP release.
> 
> - Don Gilbert
> 
> Summary of GridFTP (gt5.0.2) patches
>  -- UDT change udt4/src/channel.cpp for Solaris10:
>   add UNIX to ifdef BSD, OSX for setsockopt max buffer
>   -- UDT globus configure{.ac}: update for *solaris* and *darwin* flags
>   (always compiles with -DLINUX otherwise, also fails to configure
>   on Linux-Powerpc, were it tries assembly for wrong processor)
> 
>   -- gridftp server, anonymous ftp directories:  limit to anonymous  user 
> home dir
>   in globus_i_gfs_control.c:globus_l_gfs_get_full_path() : add  anon_user 
> path restrictions
>   (I tried chroot() first but that was overly complex to decipher).
> 
>   -- gridftp server: log_transfers, UDT client IP was 0.0.0.0 always
>   globus_i_gfs_data.c:globus_l_gfs_data_end_transfer_kickout() :  small 
> patch
> 
>   -- globus-url-copy:  set dest file timestamp to match source file  time
> (essential for -sync, usual FTP practice)
>   globus_url_copy.c: add globus_l_set_dest_timestamp() and add  int 
> src_mtime
> in globus_l_guc_src_dst_pair_t and globus_l_guc_transfer_t  structures
> 
> Here are our results to date, with testing still in progress.
> GridFTP TCP and UDT times for 113 GB transfer
> from Bio-mirror.net (Indiana USA)
> 
>Ping  Time(min)  TCP/  Distance
> SiteRTT  TCP   UDT  UDTKm  Network Route
> --
> NCSA10   139   138   1200  Indiana - U of Illinois - NCSA
>  13.9  13.9Megabytes/sec
> Purdue  17   125   125   1500  In. - Chicago - Purdue, Indiana
>  15.3  15.3Mb/sec
> ORNL25   361   120   3   1200  In. - Chi. - Nashv., Tennesee - ORNL
>   5.3  15.9Mb/sec
> TACC37   616   120   5   2000  In. - Chi. - Huston, Texas - TACC
>   3.1  15.9Mb/sec
> SDSC65----   -   3300  In. - Chi. - LA, California - SDSC
> ...
> CSTNET 274----  14  12000  In. - Michigan - Kreonet, Korea -  
> Beijing, China
>  0.48  6.67Mb/sec (from preliminary 3GB test)
> --
>   Transfer times (minutes), and below speed in Megabytes/second,
>   for TCP and UDT, and the TCP/UDT ratio.
>   NCSA, Purdue, ORNL, TACC, SDSC are Teragrid.org sites in USA.
>   Land/sea line distance is given in Km.
>   RTT is network distance as average round trip ping time in ms.
>   TCP and UDT transfers were run simultaneously from each site.
> 
> -- d.gilbert--bioinformatics--indiana-u--bloomington-in-47405
> -- gilbe...@indiana.edu -- http://marmot.bio.indiana.edu/
> 

[gt-user] Important information on Globus events and plans

[Ian Foster]

 Scrum  
development practices.


We are excited about this re-invogoration of the Globus software and  
community, and the increasing value the Globus community can bring to  
the many multi-institutional scientific and biomedical communities  
whose need for robust Grid computing middleware continues to grow  
unabated.


Viva Globus!

The Globus Team

[1] “The Anatomy of the Grid: Enabling Scalable Virtual  
Organizations,” Ian Foster, Carl Kesselman, Steven Tuecke.  
International Journal of Supercomputer Applications, 15(3), 2001.