SLAC/ATLAS TDAQ Meeting, 04 Jan 2007

Present: Sarah (phone), Stephen (phone), Matthias, Amedeo, Su Dong,
         Rainer


Amedeo/Sarah:

Discussion about the plot that Sarah has sent.  Setup is 500 nodes
with just one proxy.  The access without proxy seems to show a peak,
or clustering, around a certain time.  Su Dong suggest to find out if
that time is in the ballpark of what should be expected from the
simple bandwidth limit.  With dbproxy, times seem to be scattered
around, both later and earlier that the peak.  Question about what
starts and stops the clock.  Timing comes from dbstresser.  There
could be some offset, which is to be checked.  Rainer: how can dbproxy
be faster than direct access?  In some ways the whole picture looks
backwards.  Sarah is absolutely positive it isn't the other way
around.

Question about the nature of the dbstresser tests.  Believe that they
are asking for the same piece of information many times.  So
pre-caching should only affect the first one.  This is quite different
from the LSTs.  There, the conclusion was that the pre-caching was
removing the tails.  So pre-caching seemed what made the
difference. (Also not what one expects.)

As to running tests here at SLAC: possible issue with the database:
setting up MySQL was difficult for LST, so not sure if we are going to
run into difficulties here.  But will try.


Sarah:

CORAL is still in the same place as before. On our side made two
kludges.  On is for the 'status' command and the other one for the
change user request command (?).

Question about how stringent the requirement is to have two databases
(atlasdb and atlascool).  May be able to pursue this, but there may
even be other databases.  During LST Joerg was the only one trying the
trigger db, which would then come into the mix.  So this might be a
dead end.

Amedeo suggest to use two (or more) caches (one for each database).
This should avoid the concurrency problem.  However, this would mean
to keep track of every client.

Will talk to Radovan to find out what the access to the meta data
involves.  Non-atomicity there, might not be a real problem for HLT.

Plan to have a discussion with Radovan.  Sarah will try to invite him
for next week's meeting.  If he can't make it we will schedule some
other time.  Preparing for that we should find out about 'client meta
data accesses'.  Will study the log files to point to cases where
non-atomicity caused problems.


Other News:

Ignacio accepted our offer and will start on HLT in April.  He is
expected to work on the algorithm side of things.


Action items:

  Sarah/Amedeo/Rainer:
    Set up dbproxy tests on SLAC farm.  dbstresser should already
    work.  For HLT, complete MySQL setup.

  Sarah/Amedeo:
    Instrument proxy code for timing measurements.

  Sarah:
    Set up meeting with Radovan next week, preferably Thursday.