Level 3 Online Status Reports

Back to index Previous Next

Issue 10
Monday, June 14, 1999

Event Flow

Reports

• Data has been sent all the way from the test wedge to the test consumer. At that point it became apparent that the data format expected by the consumer is different from that which was generated by the Level 3 reformatter. An "authoritative format" has been requested.
• Jim has said (June 4) that the VxWorks license applies to where binaries are compiled, not to the computer from which the binaries and scripts are ultimately loaded. In keeping with this, the bootup scripts and binaries have been copied to b0l3pcom1 under /home/vxworks, and the vxworks "user" home directory has been redirected back to that local directory (instead of to /cdf/files, which was mounted from fndauk). The VME CPU's have been booting from b0l3pcom1 for a week.
• A refurbished (upgraded Universe) MVME2603 has been installed as b0eb25. It will go on the 1st floor for use with the SVX. Ilya has already run the requisite cables from the 3rd to 1st floor. Instructions on writing the VxWorks boot image into the flash memory are in the event builder's electronic logbook.
• No progress on ATM debugging or multiple L3->CS/L output this week.

Actions

• Jeff will continue to work on ATM debugging with Ron and Don.
• Jeff will work with Tony on multiple L3 outputs -> CS/L.
• Jeff and Ilya will build event builder executables on gobi.

Executable Interface

Reports

• Boris has assembled a small table in the online database and has a GUI for reading and writing from it. The Java code uses JDBC. A C version of the database code was also tested. Reading and writing simple data is no problem, but storing executables in the database hasn't been accomplished successfully. Sample code for the Java version can be found in cdfsga:~iyutin/java/work.
• The database caches the accesses, so a performance test would require the construction of a larger table. Boris says this can be done pretty easily for a read/write test. Single operations seem to be fast, giving fast response from the GUI.

Actions

• Performance test with larger table, giving access times for read and write operations.

Test Control

Reports

• Ilya and Sasha have been implementing different methods of the scanner control. Work continues.

Actions

• More scanner control.

Monitoring

Reports

• Mike has confirmed that ROOT's TMapFile is indeed slow. The TMapFile has to be updated by the user by invoking an update method. Looking at the source code, Mike found that, indeed, the TMapFile is really a shared disk file which is rewritten each time the update method is called, using the streamer methods of all the objects associated with the file.
• We should keep the option open for using some ROOT-like structure, since other groups are clamoring for such classes from the ROOT folks. In the meantime, Mike is wrapping C++ around Level 3 shared memory buffers. His code is to provide functionality for scalars, histograms, circular buffers, and possibly ntuples, in such a way that if the ROOT folks do come up with the mechanisms (or it comes about in another way), using those mechanisms will be a few typedef's away (actually this sounds rather like HEPtuple).
• Mike's source code can be found on b0pcmit01:~mulhearn/research/level3 and ~mulhearn/research/shared.
• Ivan has developed a "relay" object which can be used to relay remote object invocations when the target node is actually several "hops" away (akin to a gateway node talking to a processor node through an output node, for instance). His first working example was with Java and ILU, using the ILU nameserver. He now has a C++/ORBacus version. In each case, the object server has to instantiate the local server for each invocation, which raises potential performance issues.
• He is also working on a "parser" object to provide more generic routing.
• Ivan's source code can be found in b0l3pcom1:~ikfuric/work/ilu/route, ~ikfuric/work/orbacus/hello, and ~ikfuric/parser.
• Ivan has noticed that if he telnets to the ORBacus BOA port and writes gibberish, it crashes the ORBacus server. This is not surprising, of course, but it reminds us to be careful about security issues.
• We also need IPC keys reserved for the students.
• Andreas has been investigating ORBacus features that can be used to provide the information publishing service. In particular he has been trying to get the "timer" facility to work.
• In the meantime, he's gotten an ORBacus nameserver to work. As we integrate Level 3 and event builder controls, we also need to see if an ILU server can work with an ORBacus nameserver.
• Other interesting features of ORBacus which may come in handy:
  • a URL-like addressing which doesn't depend on IOR's ("iiop://...").
  • the nameserver itself publishes a special object, which facilitates having multiple nameservers.
  • the event service also publishes a special object which can facilitate different event services on different communication channels.
  • there is an info object which allows the server access to the host and port of the client connection, which can be used to verify the connection.
  • It is noted that without any special options, ORBacus executables tend to be rather large, > 2MB. However, this is not as much a problem on PC's which have lots of virtual and physical memory.

  Actions

  • Mike will continue work on his monitoring objects.
  • Ivan will perform tests of the C++/ORBacus relay object with 1 or 2 intermediate nodes.
  • Andreas and Sasha will try an ORBacus nameserver with ILU clients.
  • Andreas will get the timer object or other event service to work.

  Physical

  Reports

  • The evaluation shelf is up. There are two shelf units, and each unit has a 4'x2' footprint with four shelves. Without any loading it seems kind of flimsy, but Rob suggests that it'll become more rigid with loading (suggesting a few reams of paper might be an adequate simulation). The shelves are stiff wire mesh, which should make cabling easier. There is some concern about PC's falling off the end, but that can be solved by mounting some braces. In any cases, we need additional mounting pieces in order to cable the thing up.

  Actions

  • Revise cable requirements and discuss the shelf with Orlando

  Back to index Previous Next

  ---

  Jeff Tseng / MIT / jtseng@fnal.gov