Argonne : R. Blair
CERN : P. Golonka, K. Korcyl, S. Wheeler
Michigan : M. Abolins (in Argonne)
NIKHEF : R. Scholte, J. Vermeulen
UCL : R. Cranfield
1. Paper modeling : M. Abolins reported that he introduced the new FEX times in the spreadsheet and reduced the 11.11 % overhead to 0 (as was discussed in the previous meeitng). J. Vermeulen played with the spreadsheet using the new numbers for the scan to find out about numbers relevant for the ROS. With respect to the TP model he changed the B-physics rate to half of the original rate, introduced on average 1 electron seed and 2.6 muon seeds from the scan and assumed low luminosity optimised data compression for the TRT in the TRT RODs (for low and intermediate luminosity). He showed some numbers :
Low luminosity :J . Vermeulen concluded that the maximum of 14 kHz of request rate per ROBIn can be maintained and that it would be good to know whether there will be a maximum set for the event building rate. E.g. a ROS with 6 ROBIns could transfer for all cases all its output via a single Gbit Ethernet link if about 53 % of its capacity could be used. If the event building rate is limited to 2 kHz this number would reduce to about 31 % what is more in line with the 30 MByte/s proposed to be used as base line assumption. J. Vermeulen studied also the maximum RoI request rate per ROS : for intermediate luminosity the maximum is 20.44 kHz for the Pixels, per request the data from on average 20.4/73.7 = 3.6 ROBIns has to be requested by LVL2. For high luminosity with 75 kHz LVL1 rate the maximum is 7.1 kHz, again for the Pixels, per request the data from on average 9.4/7.1 = 1.3 ROBIns has to be requested by LVL2. Request rates like these probably can be managed.
Maximum RoI request rate per ROB : 7.03 kHz (Pixels)
Maximum data volume per ROB (LVL2 only) : 1.82 MByte/s (TRT)
Maximum data volume per ROB (LVL2 + EB) : 5.11 MByte/s (calorimeter)
Event building rate : 2 kHzIntermediate luminosity (all rates multiplied by a factor of 2) :
Maximum RoI request rate per ROB : 14.07 kHz (Pixels)
Maximum data volume per ROB (LVL2 only) : 3.64 MByte/s (TRT)
Maximum data volume per ROB (LVL2 + EB) : 10.22 MByte/s (calorimeter)
Event building rate : 4 kHzData volumes inner tracker probably too low (increase in occupancy is not taken into account)
High luminosity :
Maximum RoI request rate per ROB : 2.1 kHz (calorimeter)
Maximum data volume per ROB (LVL2 only) : 2.21 MByte/s (calorimeter)
Maximum data volume per ROB (LVL2 + EB) : 5.82 MByte/s (calorimeter)
Event building rate : 2 kHzHigh luminosity, 75 kHz, scaled :
Maximum RoI request rate per ROB : 3.99 kHz (calorimeter)
Maximum data volume per ROB (LVL2 only) : 4.22 MByte/s (calorimeter)
Maximum data volume per ROB (LVL2 + EB) : 11.09 MByte/s (calorimeter)
Event building rate : 3.75 kHz
2. ROS modeling : R. Cranfield referred to a short meeting with authors of the DAQ-1 software during the last T/DAQ week, where an outline of a document on the UML description of a model of the ROS was discussed. The diagrams produced so far are available (see also the notes of the last meeting). R.Cranfield consults J. Petersen for refining the diagrams.
3. Data Collection modeling : K. Korcyl and P. Golonka have continued with the model for the TCP/IP stack and with making relevant measurements. The "Linux trace toolkit" has been used and found to give useful information on the CPU load. For traffic generation "tcpdump" is used. P. Golonka reported that the behavioral model for TCP/IP is OK, the "TCPBroker" can now be incorporated in at2sim. Multiple connections have still to be included, while the CPU utilization model has to be developed. J. Vermeulen referred to a remark made in a previous meeting on the usefulness of a simple CPU utilization model for the paper model. It can probably can be derived from F. Saka's measurement results. K. Korcyl mentioned that the CPU utilization for a sender may be quite different than for a receiver, e.g. each segment arriving at a receiver causes an interrupt, while for a sender only a single interrupt may be generated per 5 segments output.
4. HLT modeling : S. Wheeler had nothing to report. She is still waiting for a new PC to arrive. P. Golonka looked into the sequential processing model as implemented in at2sim and is trying to understand it.
5. Reference testbed model : K. Korcyl and J. Vermeulen have now found good agreement between the two computer models and also with the paper model results for the configurations where these apply. Most results are identical within a few tens of a percent. The next step is to complete the document describing the results.
6. Ptolemy : R. Cranfield tried to "reverse engineer" the C++ support code of at2sim with "Together" and found the results not completely useful. J. Vermeulen remarked that it is mentioned on the web-site of Togethersoft that the new version 5.0 should do a better job with C++ code. The work on setting up a model for the Chiba City system is going on in Rumania after the visit of M. Brezuleanu to CERN.
7. Simdaq : J. Vermeulen had nothing to report, apart from the addition of one missing line of source code.
8. "Chiba City" : A. Bogaerts made several valuable suggestions to R. Blair during his stay at CERN. The system starts running in a 5 x 5 x 5 configuration, but stalls after less than 100 events. The cause of this problem has not yet been found.
9. Workplan and status in relation to workplan : J. Vermeulen concluded from the present status that a number of items will be completed late but that progress is being made and that it is difficult to accurately plan the type of work being done.
10. Next meeting : The next video meeting is to be held at 29 May, 16.00 h. CERN time
11. AOB : D. Burckhart has sent an email to R. Blair and J. Vermeulen asking for a Quality Assurance (QA) contact person. J. Vermeulen had answered that he was willing to act as such if nobody else would like to do it. As there seemed to be no volunteers he will assume this responsibility. K. Korcyl reported that an abstract submitted to the RT2001 conference has been accepted. A poster will be presented on modelling Ethermet switches and the TCP/IP protocol.
Notes by J.Vermeulen, 27 April 2001