(r6) ComputingT2Transfers < Main

Tags: view all tags

%TOC%
---+ USCMS T2 Transfers

This twiki was created to report the latest status on [[https://twiki.cern.ch/twiki/bin/view/CMSPublic/USCMSTier2Transfers][this initiative]].

We will have different sections for each site's notes

---+ General status

[[http://dashb-fts-transfers.cern.ch/ui/#date.interval=1440&grouping.dst=(site)&grouping.src=(site)&p.grouping=dst&src.site=(CIT)&tab=transfer_plots][DashBoard FTS plots]]

---+ Site notes

---++ Caltech

Monday 18:00 PST removed the 40 Gbps host for performance tuning. Overhead when recompiling CentOS 3.X series Kernel will cause it to come back by ~Tuesday afternoon. For now sites should expect 20 Gbps from Caltech (10+10 G setup). I don't see things too loaded though. 8G on average. 12G peak.

---++ Nebraska

Had good rates on this Friday, when we started ramping up. Had problems with their PhEDEx node which interrupted transfers at some points in the day. More stability but no major improvement on rates since then.

---+++ GFTP issues

Not sure if this is still up-to-date :

<verbatim>
Error reason: TRANSFER globus_ftp_client: the server responded with an error 500 Command failed. : Unable to extend our file-backed buffers; aborting transfer.
</verbatim>

I don't really understand the reason for this. But might be fixable with different (higher) GridFTP buffer configurations?

---++ Purdue

Found on Monday that the problem is related to LHCONE peering. Their traffic from Caltech is going through CENIC, not LHCONE, which is sub-optimal. Purdue will contact their Network support to improve this.

---+++ GFTP Issues :

<verbatim>
Error reason: TRANSFER globus_ftp_client: the server responded with an error 500 Command failed. : Allocated all 1500 file-backed buffers on server cms-g004.rcac.purdue.edu; aborting transfer.
</verbatim>

It probably ran out of memory buffers and started using Disk buffers, what in principle shouldn't happen (Brian will know more). Quick workaround would be to raise the file buffers in the configuration and restart the service, but the ideal is to find the root cause of why it needs so much file buffers.

---++ Florida

Joined last Friday, had transfers ramped up on Monday but not seeing a lot of action from PhEDEx.

---++ Vanderbilt

Joined in the first day, LStore performance is randomly anywhere from great to poor. Have seen 600 MBps in the past but not a lot right now. Found the contacts and included in the thread.

-- Main.samir - 2014-07-29

Topic revision: r6 - 2014-08-05 - samir

Account
- Log In

~~Edit~~
~~Attach~~

Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback