SLAC/ATLAS TDAQ Meeting, Apr 26, 2007

Present: Andy, Sarah (phone), Rainer

(Excused: Amedeo, Su Dong, Ignacio)


Sarah:

Farm installation: HLT software, TDAQ software, Offline software all
copied into a tar ball.  Need to go from Point 1 to a public CERN
machine, then to a public SLAC node, then to the SLAC farm (three
hops). Really feeble.

There are two directories with patches in Point 1.  One for HLT, one
for TDAQ patches.  Not gotten these over yet.  To get them included,
need to run a 'make' command.

Not entirely sure, why this would be necessary, since the Point 1
version is already patched, but was told that it is necessary for the
patches to be picked up. ->Will look at what the 'make' does when it's
run here.

One thing that was there in the TDAQ patch area was DbProxy (because
we put it there).  The other thing were patches for what was put into
the ROSes.  Might not actually need those.

The last thing is the trigger configuration database.  There is a lot
of development still going on here, and things are very much in flux.
Probably need a newer release to have support for the latest contents,
but then that release is not validated yet.  So may have to/want to
try both.  Should be able to go with what was used for the last
technical run, even though that's already superseded.

Will dump the MySQL data into an ascii file and import that.
->Suggestion to keep working snapshots so we have something to fall
back to when newer configurations don't' work with the installed
releases etc.

Started to document the SLAC import steps in the Wiki. (Tragically
lost all writeup last night, so will start over...)

Upcoming technical run: Picked up instrumentation code fix for DbProxy
from Andy (addressing timestamp glitches).  Have the pre-series
machines reserved all day today, so can test it on that. Then commit
to CVS.

Working on the structure that captures the timing next.  Will
circulate header files soon.

The other TODO item for the technical run is getting the proxy into
the partition.

Feedback from this morning's (last night's) talk.  People were
extremely interested in the profiling results.  Main question was how
this information would be fed back to the developers.  People are most
of all interested in having the instrumentation available at Point 1.
Discussed the timing instrumentations (which we will deploy) and the
profiling.  Andy and Rainer will be there for the technical run, so
can set up the profiler there, too.


Andy:

For having timestamps on all messages, Andy already sent a message to
the Gaudi team, and if that's accepted, it will add this feature as an
option.  We have to keep this optional assuming that some people may
already be parsing log files.

Rainer is puzzled as to why the configuration times came out the same
in Point 1 and SLAC farm, even though the SLAC machines are much
slower.  Most of the time appeared to be CPU time, so that makes this
even more suprising.  No idea at this point.

For messaging, there are different loggers, only one of them can
already be enabled with time stamps namely the Python one.  One of the
others covered by Andy's patch. The third may be less important but
can be done as well.

Other news (or non-news): Not received anything from MySQL in respose
to the feature request.  Also did not hear anything from the LCG team,
as to what they want to do about off-site MySQL installations.  Will
ask David Quarrie again who contacted LCG.  ->Wait for their response
and see if they are going to follow up with MySQL themselves.

Rainer had some thoughts on organizing dependencies with the goal to
reduce the number of libraries/amount of code being loaded.  If not
much attention has been paid to that yet, there are likely to be
possible improvements/surprises - unless ATLAS software is much better
organized than BaBar was at the time. [Spontaneous laughter indicated
that that may not be the case.]