Level 3 Online Status Reports

Back to index Previous Next

Issue 17
Thursday, November 11, 1999

Event Builder

• It has been noted in the test of calibration readout that the SCPU will simply truncate an event fragment which is too long without a message or other tag of the error condition. We should really have a Zephyr message and some flag in the SCPU header.
• Since a 100% occupied event will overflow the SCPU buffer, it is suggested for the future to search out a more intelligent buffer management scheme and develop a multi-packet fragment scheme. Currently the buffers are allocated at compile-time. At the very least they could be allocated at initialization.
• The event builder proxy has been coded up, and on its first test correctly sent the message "Can't connect to the scanner manager" to the run control error logger. More tests will require the event builder itself.
• Steve had to take X out of Zephyr in order to build the message forwarder on b0l3pcom1. He also removed the need to read the Merlin configuration file .mldisplayrc from the message forwarder.
• We need a zephyr ups product, and zhm startup at initialization on the gateway.
• Steve is also adding all the expanded startup messages to the event builder (e.g., the message which configures the VRB readout lists for the SCPU's, channel masks, etc.). This will entail a future update of the SCPU, SM, and VRB products relative to the "stable release" (see below).

Level 3

• Ivan presented a description of his relay object last week. It is capable of starting up the l3_converter program with its various command-line options. The capability to transfer short scripts is also planned. (These short scripts can be used, for instance, to command the transfer of a larger file, such as a calibration database file.)
• Ivan has reorganized his code to facilitate control via objects which correspond to the different ways the Level 3 farm can be divided. These objects implement the state transitions of the entire system. The objective of the week of November 15 is to make these objects into ROOT objects and use ROOT as the command-line interface for controlling Level 3.
• The Level 3 monitoring objects have been revised and used in l3_converter and l3_dump_cstate.
• Andreas has debugged memory leaks in his periodic monitoring code. He is now introducing the revised monitoring objects into his code. The week of November 15 should see periodic monitoring of l3_converter.

Integration

• A "stable release" of the event builder and Level 3 code has been put together. The version numbers of the event builder code can be found on the Event Builder home page. The Level 3 code is tagged v1_4. These versions have also been installed as ups products on b0l3pcom1, and all subsequent development is to happen relative to them.
• Christoph has also updated the rawref package for Linux. The VxWorks version will be finalized a little later.
• The stable release has been used to operate the event builder and Level 3 since Monday evening. However, a temporary patch has been made to the pstate array while the filter executable catches up.
• The three-system (TDC+ADMEM+SVX) test has been declared "done." Future integration tests may be run at the frequency of 2 to 3 per week, rather than all week as in the recent past.
• For the readout of calibration events, Frank C. has shortened the event size by removing ADMEM's. It is now less than the maximum for our ATM system (roughly 59K), and takes roughly one minute to load (the scanner manager timeout for loading events is two minutes). One event was read out and passed through the event builder without complaints, but subsequent events had a two-byte offset.
• SVX monitoring (by another VME CPU in the same crate) causes problems with event readout. The reason, as discovered by Frank W. in the VRB document, is that the VRB pipelines the readout data, and the two types of access cannot be untangled in said pipeline. Our proposed solution is to have the SCPU read out the relevant VRB registers at its convenience (that is, between events), and then write them into VME-mapped memory on the SVX CPU. We need a list of registers to read out from the SVX group. Frank W. will take care of this.

• All 15 SCPU's and the scanner manager are now available, as well as all converter nodes except b0l3c06.
• Stand-alone tests of SCRAMNet were successful.
• br/bw tests of the ATM connection were successful for every converter.
• Steve has solved slot 8 problem along with Steve Nahn. It turns out that when a CPU is declared "processor 0" in its bootup parameters, it maps some of its local memory onto the VME bus. The map happens to conflict with the slot 8 locations. The processor numbers have been changed for all SCPU's to 2.
• We have read out the VRB in the same crate as the new SRC. Formerly the SRC violated the VME DTACK protocol.
• 1->1, 1->N, 1->14 EVB tests all worked.
• "Slot 16" problem: the current "stable release" has MAX_FRC set to 16 in evbLimits.h, whereas it needs to be bigger. However, since the shift of slot number by 6 is already in, the only valid VRB slots are currently 6 to 15 (!).
• "freezing" problem: b0l3c02, b0l3c07, b0l3c10, and b0l3c16 would hang whenever anything was sent or received over the ATM. Frank W. cured this problem by taking out the PCI cards and putting them back one by one. Since we don't really know what's going on, we have to watch for this problem again. With b0l3c16 it took several iterations and hours for it to work.
• On Friday evening, got a lot of "SM Partitions: internal error. in push_builder 1" error messages in 1->1 systems. The event rate is not very stable.
• Need to understand why we are getting bus errors when SVX people access VRB registers.

Back to index Previous Next