SLAC/ATLAS TDAQ meeting, July 19, 2007 Present: Andy, Amedeo, Su Dong at SLAC; Sarah, Stephen, Ignacio, Keith, Dan at CERN Sarah/Keith/Dan met with Andre dos Anjos who has taken over the main responsibility of the PartitionMaker. This initial meeting was mainly introductory and not yet on a specific on project. Some possible next steps include e.g. a) looking into more convenient ways to set a single partition variable using DBproxy usage as a guide b) utilities to check consistency of partition. With ourselves involved in some of the more complex parittion setup issues, we may be in the best position to help where this should go. Sarah: Given the busy scheduling of the roduction system, there has been official encouragement and movement toward more utilization of the pre-series. We need to help on the pre-series partition setup in some of the cases. News from Commissioning: The next Technical Run and M4 Commissioning run will not use algorithms in the HLT beyond the cosmic slice. The next time algorithms will be seen in an official online test week will be in the autumn Technical Run, at the end of September. The DbProxy will be a part of the next HLT release, scheduled to be built within the next few days. To-Be-Followed-Up: - adding an environmental variable to the proxy code that specifies the server the proxy should connect to. (This variable can then be defined at the segment-level, allowing for one DbProxy TemplatedApplication in the entire partition.) - CORAL connect issue/ example in HLT code of CORAL interaction. (Everything I can find is an interaction through StoreGate, but I wasn't able to put much time into this before leaving for vacation.) - fix from Hans with Geometry Database (ATLASDD) Su Dong: Met with Dario/Richard/Fabiola briefly at Glasgow to discuss the evolution of Pool files vs ORACLE. Dario's original perception was that ORACLE was meant to store only smaller objects, while large repetitive constants would go with pool files with a pointer in Oracle. This largely stemmed from the belief that performance of Oracle in handling large objects is doubtful. Richard didn't agree with the assessment and is hoping there will be a unified solution going to Oracle so that one only needs to support one technology. I think some realization may be still missing in many people's mind of the penalty of keeping the support of the pool files (Sasha Vaniachine's DB ddeloyment/distribution talk at Glasgow didn't even mention that configuration DB and trigger config DB also need to be distributed like conditions). Given only LAr and TileCal are still steaming ahead with the Pool files, Dario/Richard agreed to ask what it takes for them to convert. At the mean time, verifying ORcale can indeed handle large objects (at least in the binary form) gracefully may be a necessary step to ensure the migration is heading in the right way toward Orcale in one shot. Richard emphasized that people are getting anxious to see the DBproxy compatibility with Oracle. He was the only one doing Oracle->mySQL replica tests and has concerns in the performance for the long run when the Oracle DB becomes very large. DBproxy log monitoring code is progressing slowly while running between meetings. The plotting part is now also working, but still need to investigate the possibility of running ROOT at point. After getting better understanding for some very large DeltaTime entries, the code/result will hopefully be released bvery shortly. Andy: Established a regular dialog with Dirk Duellmann who is the sole survivier of the COOL/CORAL team layoff. There is an ad out to hire new developers by end of Aug. At some point, the thoughts of out sourcing the work to e.g. India even came up, but it is rather doubtful the effectiveness given the typical local interactions needed with the customers, like us. However, Dirk would appreciate some supporting voice from ATLAS formally transmitted to IT to emphasize the importance of maintaining the CORAL support at IT. An official priority list from ATLAS would be also very helpful to allow them concentrate the limited resources. We should follow this up through TDAQ management to get our pitch in. Supporting pool files through Xrood: CMS is using pool files in a big way and may already have something close to what we need. Dirk is looking at the possible pluggin code they have and hopefully there is a simple path from there. Making DBproxy to speak CORAL as the internal language is a rather attractive path to gain compatibility to everything, including Oracle. However, this involves some new CORAL protocols to just pass along the requests/replies. Fortunately, Dirk is also inclining to move in a similar direction because there are some evidence of degraded performance of Oracle when there are too many connection so that he is thinking about an arrangement of CORAL serving proxies. So he is very interested in a collaboration on this. Andy will be on a rather long vacation in a week time, any help from him needed should be piped up in the next week. Amedeo: Making DBproxy to speak CORAL as internal protocol may be an easy change as the the design was trying to avoid specific interprettations and just passing along request. On Oracle support, both Amedeo and Andy thought that just looking at the SQL-relay code may get some clues if there is also a practical way of implementing it from borrowing part of SQL-relay ? How about taking one of our previously considered option of running a Oracle/mySQL translator at the top proxy using SQL-relay ? Andy thought the input Oracle->mySQL translation may be fine, but the return path of mySQL->Oracle might be tricky. This also has some performance penalty for the translation. Ignacio: Got a partition with gatherer running on SLAC farm. Will be giving MET slice performance talk at the Tuesday MET slice meeting. Will try TDAQ release 1.8 soon. Keith/Dan: Making good progress on running slice validations (as reported in the group meetings).