Hi Gerri,
Yes, we are eager to test the new 5.18 branch.
And binaries for slc4_ia32_gcc34 would be great. Thanks!
Is it possible to compile it with MonaLisa flag ?
We would like to test ML based monitoring framework for PROOF too.
Cheers,
Sergey
Gerardo Ganis wrote:
>
> Hi Sergey and David,
>
> Are you in the position to test 5-18-00-patches and tell us if it
> works better?
> The branch should have already all the fixes that we thought
> necessary. If that is OK for you there
> will be no problem in tagging 5.18/00e .
>
> Cheers, Gerri
>
> PS: I can make binaries for a couple of platforms if that can help in
> testing; just let me know the
> platforms/OS/compiler, i.e. which of the config strings you
> use (e.g. 'slc4_ia32_gcc34').
>
> Sergey Panitkin wrote:
>> Hi Fabrizio,
>>
>> I would like to add to Andreas' comment about root 5.18.
>> Latest production release of Atlas software- which is intended for
>> data taking- is based on version 5.18. That's just the nature of long
>> development cycle.
>> From our point of view, a new, patched version of 5.18(e?) with xrootd
>> client fixes is necessary.
>>
>> Cheers,
>> Sergey
>>
>> Fabrizio Furano wrote:
>>> [bounced to xrootd-l]
>>>
>>> Hi Andreas,
>>>
>>> yes, afaik it's fixed, and the tests performed around report that
>>> it is ok.
>>> 5.18 is very old now, and I would recommend that users switch to the
>>> newer releases. But I guess that Gerri can point the users of older
>>> root releases to a patch for the netx package, which at least
>>> contains that fix.
>>>
>>> Fabrizio
>>>
>>> Andreas Joachim Peters ha scritto:
>>>> Hi Fabrizio, David found a memory leak using LHCb analysis in
>>>> XrdClientReadCache which apparently was fixed recently by you.
>>>> Do you have any good recipe to suppress the problem using the older
>>>> root version 5.18.00? Will it help to set the ReadCacheSize to 0?
>>>>
>>>> Cheers Andreas.
>>>>
>>>>
>>>> ---------- Forwarded message ----------
>>>> Date: Thu, 31 Jul 2008 14:42:18 +0200
>>>> From: David Smith <[log in to unmask]>
>>>> To: Greig A.Cowan <[log in to unmask]>
>>>> Cc: Andreas Joachim Peters <[log in to unmask]>
>>>> Subject: Re: DPM xrootd failures
>>>>
>>>> On Jul 28, 2008, at 6:11 PM, Greig A. Cowan wrote:
>>>>
>>>>>
>>>>> On 28/07/08 16:55, David Smith wrote:
>>>>>> It's probably the only way I'll be able to help you understand why
>>>>>> there
>>>>>> is such large memory usage here. From the DPM point of view I
>>>>>> think it is
>>>>>> unlikely that it is anything specific to the DPM-xroot usage, but
>>>>>> unless I
>>>>>> check I can't be sure.
>>>>> You can find the options file on AFS:
>>>>>
>>>>> ~gcowan/public/optsfiles/Bs2Dspi_signal_sel_greig.opts
>>>> [...]
>>>>
>>>> Hi Greig, Andreas,
>>>>
>>>> (apologies for the line wrapping my email client is probably going
>>>> to do)
>>>>
>>>>
>>>> The majority of the leak is due to
>>>> XrdClientReadCache::SubmitRawData() in
>>>> XrdClientReadCache.cc. The code in the executable corresponds to
>>>> this snippet:
>>>>
>>>> if (pos >= 0) { itm = new XrdClientReadCacheItem(buffer, begin_offs,
>>>> end_offs,
>>>> GetTimestampTick()); fItems.Insert(itm, pos); fTotalByteCount +=
>>>> itm->Size();
>>>> fBytesSubmitted += itm->Size(); } return true;
>>>>
>>>> quickly looking through CVS I see a recent (5 weeks old) revision in
>>>> the
>>>> root/xrootd repository changing it to:
>>>>
>>>> if (pos >= 0) { itm = new XrdClientReadCacheItem(buffer, begin_offs,
>>>> end_offs,
>>>> GetTimestampTick()); fItems.Insert(itm, pos); fTotalByteCount +=
>>>> itm->Size();
>>>> fBytesSubmitted += itm->Size(); return true; } return false;
>>>>
>>>> (see
>>>>
>>>> http://root.cern.ch/viewvc/vendors/xrootd/current/src/XrdClient/XrdClientReadCac
>>>>
>>>> he.cc?view=log
>>>> )
>>>>
>>>>
>>>> changing the binary to be equivalent to this fixes the worst of the
>>>> memory
>>>> usage.
>>>>
>>>> Andreas, do you know more about the specifics of this, e.g. if there
>>>> is a
>>>> version of the analsyis framework might have the change included -
>>>> or if this
>>>> particular problem has been discussed with a some other recommended
>>>> workaround?
>>>>
>>>>
>>>> Yours,
>>>> David
>>>> --
>>>> -------------------------------------------------------------------------
>>>>
>>>> David Smith e-mail: [log in to unmask] tel: +41 22 76
>>>> 70677
>>>> Address: D. Smith, CERN G20800, Bat 31 2-003, 1211 Geneva 23,
>>>> Switzerland
>>>> -------------------------------------------------------------------------
>>>>
>>>>
