Participants :

Argonne : R. Blair,
CERN : K. Korcyl,
Irvine : A. Lankford
Michigan : M. Abolins
NIKHEF : J. Vermeulen, R. Scholte
UCL : R. Cranfield.

1. Paper modeling : M. Abolins reported that (i) the note by S. Gonzalez (ATL-COM-DAQ-2000-025 ) shows that a 1 sigma cut on the noise for the calorimeter reduces the algorithm execution time with a factor 2 - 3, (ii) contact has been established with Ilias Efthymiopoulos to see what the possibilities are for reduction of the calorimeter data volume, (iii) contact has been established with Simon George with respect to the trigger list. There are no changes so far, but uncertainties in the rates are probably a factor 2-3, a study by Valerio Vercesi and Stefan Tapprogge is expected to provide more insight.
M. Abolins reported also that he is becoming familiar with the spreadsheet. J. Vermeulen mentioned that in his view use of the new input information in the spreadsheet is somewhat less important now (but of course should not be neglected) than collecting it.
For the work on the paper model there is a milestone at June 1, having an overview a month earlier of the available and missing input is desirable. The trigger/DAQ week foreseen for this spring provides a natural point in time. A. Lankford mentioned that the week is foreseen to be held in the first week of April.

2. ROS modeling : R. Cranfield is working on an UML description of the Ptolemy code of B. Rensch in order to gain experience with Together and to see what is a good way to specify the model. He reported some problems (sometimes long response times, windows which become very small) with running Together on his linux machine, which were not observed by J. Vermeulen in a Windows environment and also not in a linux environment. The problems may be specific for the environment on his machine. The most useful type of diagram seems to be the collaboration diagram, more work is required. J. Vermeulen also reported on using the tool, again with the purpose of obtaining experience and to find out about what is a good way to represent the model. It is tried to reverse engineer part of simdaq. It has been found that the tool did start to behave not well (in particular the "Edit definition" option in the menus does not work or even disappears; this option is used for accessing the source code) if the standard file extentions (".cpp" for C++ source under Windows) are not used. Re-installing the tool and using the standard extentions seems to solve the problem. Another problem was found with the automatic generation of sequence diagrams : a number of method invocations and function calls are skipped. It has been unsuccessfully tried to find the reason for this. The conclusion is that these diagrams need to be edited by hand. Class diagrams were found to be OK, in particular the pointers in objects pointing to other objects show up in the class diagrams, this was found to be a useful feature. R. Cranfield noted that editing files "outside" the tool gives rise to problems. The exercise should lead to having available at the end of January some diagrams, which also can serve as guide for the other groups on how to use UML for documenting the models.

3. Data Collection modeling : K. Korcyl worked on the testbed model and has no progress to report.

4. HLT modeling : S. Wheeler could not be present, as reported in the previous telephone meeting she intends to start work on HLT modeling in the near future. From the beginning of February a new Polish student will also be active in this field.

5. Ptolemy : R. Cranfield reported that the Java version of the tool will be studied by R. Hughes-Jones, that a connection with the people in Bucharest has been established and that at2sim is now running there. K. Korcyl reported on further study of the testbed model and comparison with simdaq results. Problems in the Ptolemy model and parameters were located so that now a better agreement between the measurement results and the Ptolemy model and therefore also between the two models has been obtained. The new results will be made available via the web (note : at the time of writing this note a mail has been sent announcing the availability of the spreadsheet and with more information on the work done, this mail is appended to these notes). R. Cranfield asked about the differences in the results of the two models. K. Korcyl mentioned that there are still differences in message sizes and less important parts of the models (see for more information his email). R. Cranfield next reported that the work on sequential processing still needs to be done. A short discussion on whether the telephone conferences on the work with Ptolemy (held every two weeks on Monday afternoon) should be announced via the modeling list led to the conclusion that this indeed should be done, but without specification of the details. The meetings are open, persons interested can contact R. Cranfield for participation.

6. Simdaq : J. Vermeulen spent his time on getting familiar and experimenting with Together, see point 2. He remarked that making a model of the testbeam setup of last year is the next step with simdaq, which also can be seen as a step in the direction of a model of the ROS.

7. "Chiba City" : R. Blair reported that running the system is not yet succesful, but that he is close to the point where runs can be done. The associated milestone (of January 1) was set too early in time and needs to move into February. The communication protocol will first be UDP, then TCP/IP and Myrinet. R. Blair will find out about the details of the system and make this available to the group in Bucharest, which is interested in modeling the system. There is already a Powerpoint file available with the lay-out of the system, a further piece of information is that all nodes are identical.

8. Workplan : the comments from R. Cranfield on the workplan circulated the day before the meeting made it clear that the workplan still has to be finished and to be sent to the ROS, DC and HLT groups. In a short discussion on the first task the point was made that the component models are not generic but those used for testbed modeling (i.e. the LVL2 testbed and the Chiba city system). A. Lankford mentioned that there probably will be no measurement results from the phase 1 system. J. Vermeulen remarked that the phase 1 system then should be used as source of inspiration for developing the phase 2 system model. A discussion on the meaning of the abbreviation "FTE" led to the conclusion that this represents the manpower provided by a single person working for a full year, and is equivalent to a "FTEY", where Y stands for "year".  R. Cranfield's and J. Vermeulen's impression is that, taking into account the new Polish PhD student, we may have about the right amount manpower available for modeling. J. Vermeulen noted that for the milestones for early this year the effect of the Christmas holiday may have been underestimated. It was also discussed how to go about the workplan. The suggestion is that R. Blair circulates an updated list via the mailing list, asks for comments to be sent within a week and then sends copies to the ROS, DC and HLT group leaders asking for comments.

9. Next meeting : With respect to the meetings for the end of January A. Lankford remarked that these meetings have been foreseen, but not organised. J. Vermeulen concluded that it is too late to organise travelling, and proposed a next telephone meeting in three weeks. However, on Tuesday 6 February there seems to be a ROS meeting planned, so the proposal made is Wednesday 7 February, 16.00 h CERN time. Everybody in the meeting agreed with this, this is to be circulated via the mailing list for comment. The next ATLAS week is from 19 - 23 February, this seems to be a good opportunity for a face-to-face meeting.

10. AOB : There were no other items to discuss.

Notes by J. Vermeulen
 

========  Mail from K. Korcyl =======================

Dear Modelers,

As announced at the last phone conf I put on WEB the recent results of
studies on comparison between simdaq and Ptolemy models of the
Application TestBed setup.

You can fetch the Xcel spreadsheet from:
http://nicewww.cern.ch/~korcyl/Ptol-simdaq-comparison.xls

The original discrepancies (mainly between Ptolemy and both measurements
and simdaq which were nicely correlated) were resolved by changing the
logic the Ptolemy steering model was coded.
In both environments the model of steering on receiving the ROI data was
parameterized as:
      receiveRoI = receive_roi_time + steeringRoiReceiveFloat * RoIsize
(more details on that in the ATLAS note: ATL-DAQ-2000-039)

The simdaq model - which nicely reproduced results from measurements - was
using 'receive_roi_time' when a ROI fragment from a single ROB has been
received, whereas the 'steeringRoiReceiveFloat'Ýwas used only after all
ROBs responded. The RoIsize was then the size of the whole ROI image (sum
of data from all ROBs). After that the simdaq was starting the fex
processing.
In the Ptolemy we were using the full formula any time we get data from
ROB. After replies from all ROBs were collected and processed that way the
fex processing could be started.

In addition the simdaq model introduced another parameter (not mentioned
in the ATLAS note) which accounts for subsequent ROI requests generation
in case there are more than one ROB to be contacted.
Originally we had (the ATLAS note) single constant time for ROI request
generation: ROBRoIDataRequest_prepare_time. In modifications proposed in
the simdaq the RoI requests generation is paramereterized by following
formula:
   requests_prepare_time = ROBRoIDataRequest_prepare_time +
                                   subsequentRoIRequest * (n-1)
where n defines number of ROBs the ROI data has to be collected from.

And finally, Jos found better values for some parameters. At the
time we were writing the ATLAS note we had measurements from very simple
setups. In some cases constant time had to be split into two
parameters and there were not measurements available on how the split should
be done. Therefore only with results from more complex setpus the better
values for such parameters can be deducted.

For those interested in more details here is a list of parameters used in
the modified Ptolemy model of steering (parameterized models of Super and
ROB are identical in both environments):

receive_event_time: 40 us
subsequentRoiRequest: 19 us
ROBroiDataRequest_prepare_time: 80 us
fex_process_time: 45.3 us
receive_roi_time: 20 us
steeringRoiReceiveFloat: 117ns/byte

There are still number of differences remaining in the two models:

1. Processing ROI requests:
- In the simdaq all ROI requests are generated at the same time and given
to the process which will serialize them when sending off to the network.
The time of generation is calculated based on the formula mentioned above.
- In the Ptolemy the first ROI request is generated at
'ROBRoIDataRequest_prepare_time' and given to the network. The next
request will be generated 'subsequentRoIRequest' later and given to the
network.

2. Sizes of messages:
- In the simdaq the size of messages is taken from the ATLAS note ??
- In the Ptolemy we use vales from the Reference Software header files:
  SteerEvent (Super -> Steering)       56 bytes
  ROIRequest (Steering -> ROB)         44 bytes
  ROIData (ROB -> Steering)            32 bytes + fragment size
  SteeringComplete (Steering -> Super) 28 bytes

3. and perhaps something else as the two models still produce different
results, however much more correlated than before (at the November TDAQ
workshop).

As the work still continues...
any comments and suggestions are welcomed and awaited,

Kris.