SLAC/ATLAS TDAQ Meeting, 1 Feb 2007

Present: Stephen (phone), Sarah (phone), Andy, Steffen, Amedeo, Rainer


Stephen:

Regression tests still show differences in e-gamma/tau slice.  Some
hope that in 12.0.5 this might go away. (But not clear.)


Sarah:

LST report: now official that the presentation is next Thursday, Feb 8.
Sarah will give the report on DBStressor and dbproxy tests (10 min).

Test at Point 1: Went to the pre-series meeting to learn about the
schedule.  Technical run is pretty much mapped out through June:

Feb: Commissioning TDAQ-1.7
Mar: Full slice test with TDAQ-1.6
May: Commissioning TDAQ-1.8
Jun: Full slice test with TDAQ-1.8

Have to see where the proxy would fit in.  Depends a bit on whether we
have something for SQLRelay.  May even be part of the slice tests in
March, but certainly in May.  Focus of these tests will be running all
slices; ideally dbproxy could/should just be an integral part of that.

SLAC Farm: Have been running partitions on the entire farm.  At least
45 nodes.  Some trouble with running the proxy.  Amedeo helping with
that.

Now have instructions for running without the GUI.  Text interface is
probably the right way to go.  Running different numbers of nodes.
Results are pretty strange.  (Already w/o the proxy.)  Haven't been
able to repeat the test with the proxy yet.  Didn't understand why the
MySQL server would wait 160s.  This seems at least to confirm the odd
behavior seen during the LST.

Looking at the DBStressor controller code.  Some of the weirdness may
be come from there.  Will repeat the L2/EF test next.

Where to put the information?  Decided to ask for a our own space on
the TDAQ Twiki page.  Will compile results of specific tests, for us
to discern a pattern.  Would certainly be nice to have a clearer
picture before the report next week.


Amedeo:

SQLRelay: Will resume work on this tomorrow and part of next week.
Plan to create our own DBStressor to run in a very controlled way.
Will start one proxy plus a client on every machine.  If that is fine,
then will move to the official DBStressor.


Andy:

Reading up on POOL/COOL.  Learned a few things.  Could use xrootd
protocol to serve the data.  Do we want to implement xrootd inside
dbproxy?  Or a simpler protocol?

File catalogue returns abstract address inside the file.  Maps the
object ID to the location of the object.  It takes several objects to
extract from the ROOT file to find the one you need.  That means you
get several pieces of data from the file not just one.  Question is if
they all have to be cached and how.  Defining the object and locating
it are two different things.  Finding is done on the client side,
which takes multiple requests back and forth through the ROOT tree
structure.  How to construct the cache?  Andy/Amedeo/Rainer take this
offline.