Level 3 Online Status Reports

Back to index Previous Next

Issue 9
Monday, June 7, 1999

Event Flow

Reports

• Weekend tests using the trace utility show that the 15ms delays between every 5th or 6th PDU interrupt (when ATM fragments have been completely received by the adapter) are the result of waiting for the next event, i.e., the 10 fragments of a single event are received in 5 or 6 overlapping interrupts (some interrupts prompting the reading of more than one fragment) in a single burst.
• When the trace is stopped several events beyond a tardy fragment, it is seen that one of the receiving threads indeed does not "click" when the others in its builder click; its click comes in the next group of interrupts (which corresponds to an event read by the next builder). This suggests that the interrupt for that tardy fragment is lost for some reason (coming at an inopportune time while the computer is processing other interrupts?), and that the fragment waits for the next interrupt to be read, which of course only happens after its own event has timed out.
• Connectivity achieved from wedge crate (b0ccal00) to the consumer server. The data logger has written data to disk, but the consumers at the time could not read the little-endian data.
• One wedge test problem was that the CS/L code was expecting the 32-word pointer section to exist in the begin_run record. In order to get around it, Tony removed that section of code. It is noted that there is no reason for the 32-word pointer section in the begin_run record, and a preference to confine it to run_event records. We have to make sure this is consistent with the way new executables generate begin_run records (see next section).
• The VxWorks stuff on gobi has been upgraded. We now use the following

          % setup -q mv2603 vxworks v5_3b
          % setup -q ppc vxworks v5_3b
  

  to use the old stuff. The new stuff is version 5.3c.
• Jim has added all the EVB/L3 graduate students to developer lists for Level 3 and event builder (cdfevb). They can now check software out from the online repository on b0dau30.

Actions

• Jeff will continue ATM debugging with Ron and Don.
• Jeff will work with Tony on multiple L3 outputs -> CS/L.
• Wedge test continues (Ilya).
• Jeff will begin the migration of VxWorks stuff from fndauk to gobi, at the same time tidying up.

Executable Interface

Reports

• Kevin's last executable was last Friday. It was built against the Level 3 cvs tag RunII_v1_1, and correctly accounted for the 32 words between the message header (WIN header) and event data. However, while it constructed the TRYBOS record data for the begin_run record, it did not construct a WIN header. As a result, the (sink) output mode saw a zero logical length and subsequently did not send the event data, though it sent the handshaking messages correctly.
• Christoph and Ilya have the new reformatter working with its new interface. It is packaged as a ups product, but this needs some reorgnization. Reformatting in the converter node still doesn't work: the event is reformatted and sent to the processor node, but it gets "stuck" there, presumably because of a badly formed header.
• Boris has extracted some potential database fields from the test kludges. These will be presented to Umesh to insert into the online database. Accounts with the online database are also needed.

Actions

• Ilya and Jeff will test next executable, fix bugs, etc., when it comes.
• Jeff will check to see if the converter reformatter is getting stuck due to the faucet output.
• Christoph will reorganize the packaging of the reformatter.
• Boris, Ilya, and Christoph will get together with Umesh to gain access to online database and insert fields.

Test Control

Reports

• Ilya and Sasha have rebuilt ILU in its Linux and VxWorks manifestations and gotten Steve's example to work. A problem that has been found is that it doesn't correctly pass sequences of strings (previous tests had contained sequences of structs of ints).
• A new scanner control has been begun which will replace both the old sctl as well as the UCI (test3_uci, in the control kludges). This is expected to take several weeks.
• Sasha implemented a reboot method, but then ran into the problem that the reboot has to be run in a delayed thread so that the server has time to shut down properly.

Actions

• Ilya and Sasha will encode state transition commands as integers rather than strings, and write the new test control.

Monitoring

Reports

• Mike is implementing the TMapFile benchmark to examine its performance (in light of Kaori's observation that TMapFiles are much slower than normal memory segments). He hopes to have some measurements by Tuesday.
• Ivan is implementing some experimental communications ideas in ILU, and has already written an IDL and some Java code. This code is intended to eliminate the need for explicit routing, but still without using usual Internet routing, so that the gateway node need not maintain hundreds of connections.
• It was found that ILU's original C++ binding is deprecated, and the new, CORBA-compliant one only exists in a relatively untested and incomplete Visual C++ implementation.
• Sasha has shown that an ORBacus (Java binding) client can interoperate with an ILU server. ORBacus also has an apparently mature CORBA- compliant C++ binding. Steve built ORBacus on b0l3pcom1 last April, also installing egcs and libstdc++, which are required. Jeff has rebuilt ORBacus along with JThreads/C++, a package by the same company which allows C++ multithreaded programming a la Java threads.
• Steve Tether's IDL style guide can be found here.

Actions

• Mike will work on TMapFile benchmarks.
• Ivan will implement experimental routing ideas in ILU, perhaps ORBacus later.
• Andreas will build applications with ORBacus C++ binding.
• Need to settle issue of using ORBacus or ILU.

Physical

Reports

• Rob reports that the evaluation shelf has arrived, but hasn't been put together yet. Should be done this week.
• Jeff and Orlando discussed Jeff's first pass at the list of cabling requirements. One major suggestion was to use fiber trunks instead of individual (or duplex) fibers between the first and third floors, with optical fanouts on either end.

Actions

• Get Orlando's help once the shelf has been constructed to discuss mounting solutions.
• Revise cabling requirements list.

Back to index Previous Next