Level 3 Online Status Reports

Back to index Previous Next

Issue 7
Friday, May 7, 1999

Event Flow

Reports

• Tony has operated the L3->CS interface for 5000 events.
• l3_dump_cstate and l3_converter have been updated to include the l3recv variables l3get, l3late, and l3ioerr. It can also now call l3wait() when the run begins.
• Tests concerning packet losses:
  • count packets: driver always seems to count one more event (that is, the number of fragments that make up one event) more than the converter node registers. Should try to understand why this is so, but it at least indicates that the node is receiving all the data it's supposed to be receiving.
  • decrease packet size: no noticeable change.
  • loosen rate limitation: no noticeable change.
  • increase timeout window (20 tries to 200 tries): reduces drops; overnight test gave 9 fragments dropped out of > 2.3M events (10 SCPU's, so 23M fragments). All these were registered in the l3late counter, and nothing in l3ioerr.
• It is pointed out that if the ATM driver on the SCPU returns control to the calling task after the DMA into packet memory, then SCPU could be notifying the SM that it's done sending before even previous packets have been sent. Therefore the timescale for l3wait should actually be a multiple of the transmission time (with 12KB fragments, nx12ms), which could potentially use up the 30ms timeout period initially used. There are 30 packet buffers on the ATM interface. This issue could be investigated using a histogram of available buffers on the SCPU, as was used when debugging the "rate break" phenomenon of last year.

Actions

• Jeff will integrate l3bg.tcl and evb.tcl.
• Jeff will update L3FarmUser.java to control just processor nodes.
• Wedge test: from wedge to consumer server.
• More tests to try, to find out what increases the packet drop rate:
  • use the "date" command, which executes at high priority, to induce packet drops.
  • "nice" the l3_converter program and then run a program (tiny?) over it.
  • Look into i4515_driver to see when its transmit routine returns. Possibly rejuvenate buffer histograms in SCPU.
• Large system test for May 19 review.

Event Builder

Reports

• The Trigger Manager will be in the same SCRAMNet ring with the SCPU's and converter nodes. The TM will have a separate ring to communicate with the Trigger Supervisors.
• There is pressure to put VRB monitoring on the same computer running the SCPU code. The ROBIN folks are trying to make sure that ROBIN will be "friendly" with it, considering such issues as the memory management and memory maps of the VME space. It is also observed, however:
  • monitoring has a tendency to grow and change very rapidly; it is very likely that as monitoring needs are identified, the pressure to implement them will force the use of the upgrades without adequate testing. In the unprotected VxWorks environment, this could easily crash the DAQ software itself. It must be a priority to take data.
  • it will also be nice for the monitoring people to be able to modify/download new code without having to stop the DAQ.

Actions

• Steve will express our concerns to Jim. Other input regarding this issue is welcome.

Executable Interface

Reports

• Data generation on SCPU works. It has been implemented as the VRB object vrb_simu.
• Christoph has made the raw reformatting code into a UPS module on Linux. This should enable the various pieces of code which depend on this code to declare a dependency, and it also eases the setup.

Actions

• After May 19, encapsulate all the products in UPS.
• Also after May 19, move VxWorks source platform for the Level 3 and Event Builder from fndauk to gobi.

Test Control

Reports

• Ilya has implemented a C server in ILU which uses exceptions, where the C server generates the exception.
• Steve found that 2 years ago, someone else adapted ILU to VxWorks, but that was version 9 (present version is 14). However, it indicates that Steve has been going in the right direction.
• TAO is reported to be 1MB by itself. ILU comes to about 700K. Our goal is to have at least 10MB available for SCPU buffers, which limits us to 6MB of software. The SCPU code itself is 915KB.

Actions

• Continue with ORBacus/ILU.
• Steve will continue on ILU port to VxWorks.
• Steve and Jeff will make sure we comply with Run 2 run_control state machine.

Monitoring

Reports

• No progress to report.

Actions

• Ivan and Andreas will continue DIM investigations.
• Mike will continue with ROOT monitoring development.

Physical

Reports

• No progress to report.

Actions

• Jeff will compare the two network layouts as they pertain to a Level 3-sized system.

Back to index Previous Next