CMS Site Log for PHOENIX Cluster

Go to previous page / next page of CMS site log

10. 2. 2007 Cleaning of data sets from SE

I cleaned several data sets from our DPM, since no more space was left (one shared pool from LHCb which we had opened to all had never been used. Seems to be a DPM problem). A number of production jobs had failed in writing to our storage, but the problem was only detected when the production team ran the merge jobs. The files exist in the nameserver of DPM, but there are no connected SFNs for them. They can be detected easily, since they show up as files with 0 bytes file length on commands like edg-gridftp-ls --verbose or rfdir. Gave this feedback to Alexander Flossdorf from DESY.

12. 2. 2007 Test of PhEDEx 2_5_0_1

Tested Dev instance of new PhEDEx distribution. Subscribed to /phedex/monarctest_CERN/1 data set The files were routed from PIC and the FTS at FZK seemed to work fine.

After half of the files had completed, there was again the typical error for many transfers.

Failed Transfer failed. ERROR the server sent an error response: 425 425 Can't open data connection. timed out() failed.

The PhEDEx monitoring page showed, that T1_PIC transfers to a whole number of other sites also were problematic. But I found for every other site a different error.

Since we are currently busy getting the new dCache SE up and our old DPM SE has not much space available, I just started the PhEDEx Prod instance, but did not subscribe to new data right now.

20. 2. 2007 started Cycle-1 / Week-2 exercise

Following the plan laid out in Daniele Bonacorsi's pages I signed up T2_CSCS for a number of MONARC test samples in the Dev instance, after making sure that FZK had the same subscriptions (FZK had no subscriptions in Prod, so I chose Dev). After fixing a trivial error due to myproxy, we began to get the files at almost 30 MB/s from IN2P3.

21./22. 2. 2007 myproxy renewal problem / no source files from IN2P3

Due to a myproxy renewal problem on our side the transfers of last night failed. There have been multiple attempts to transfer from FZK.

All the following routings picked IN2P3 as a source, even though the requested files had already been erased there (so there was an inconsistency in TMDB and what the center had on disk). The problem was corrected the following day. I cancelled all subscriptions in the Dev instance and subscribed to a new set of monarc test files in the Prod instance.

These graphs show load generated by transfers from FNAL:

In the evening transfers from FZK began to kick in with reasonable efficiency:

Go to previous page / next page of CMS site log

-- DerekFeichtinger - 20 Feb 2007