[Halld-online] [New Logentry] DAQ Testing

davidl at jlab.org davidl at jlab.org
Tue Jul 8 11:40:02 EDT 2014


Logentry Text:
--

We met to continue the program of large scale DAQ testing. 

Participants:  Sergey F., Vardan G., Carl T., Dave A., David L.


- Setup to run from hdops account by installing from hdsys account

  - Installed new DAQ using hdsys into /gluex/daq/daq_dev_vers.
    To use this, one must do the following after logging into the hdops
    account:

      source /gluex/daq/daq_dev_vers/work/online_setup.cshrc

  - Changed permissions on “log” and “ddb” directories in cool so
    that hdops can write to them
  - Changed gluon50-daq to just gluon50 in ~/.rcm.ini so that ethernet
    interface would be used instead of IB. This was done because the
    IB interface is currently down
  - Removed the setup.xml file installed by default in $COOL_HOME/gluex
    since it was causing the platform to try and use “furletov” and “gluon50”
    instead of defaulting to the local machine (gluon02)
  - Built the mcROL.so in $DAQ_HOME/vme/src/rol_soft. Also modified
    the online_setup.cshrc script to set CODA_ROL to this directory

- 2 crate configuration: SoftROC

  - Started up rcm.sh and selected:
      RUN: TEST
      SETUP: SoftROC
      TRIGGER: PULSER

  - All components started OK (platform, PEB, ER, ROCSTPSC1, ROCSTPSC2, rcgui)
  - Configure failed. RTVs not set. Message is buried in exception from platform.
  - Tried resting and configuring again. RC again reports error “Control Supervisor is no registered”
  - Stop all components via rcm and restart
  - Noticed message from platform: “tee: log.platform: Permission Denied”. Both log
    and lock files appear to be in place however in the $COOL_HOME/gluex/log directory
    with correct timestamps and owned by hdops
 - setup.xml needs to be writable by hdops
 - rcm config. is in both .rcm.ini and a file in work. The /work file saves last settings
   and is used for storing last settings used. These may need to be consolidated.


At this point we switched over to testing the 50 crate system from Sergey's account.

- Testing 50 crate system fast startup and shutdown

  - Attempt 1
    - All crates except roctrig1 started. roctrig1 was not responding to ping. Crate
      was power cycled remotely via:

      rocs.sh trig:1 

     (syntax is: basename:num1,num2,num3,..NumN  or basename:num1:numN

    - roctrig1 came up OK and restarted all components. started is much faster (few seconds)
    - tested fast shutdown of components. It worked within a few seconds as well

  - Attempt 2
    - Configure failed due to some components connecting to the wrong gluon
      due to the direct connection being set to a different node than we’re on.
      (we’re using gluon50 and configuration used gluon53). Switching to using
      gluon53

  - Attempt 3 (using gluon53)
    - Configure succeeded
    - Download succeeded
    - Prestart succeeded
    - Go succeeded (forgot to start softROCcontroller)

  - Attempt 4
    - Reset and try again. (don’t kill any components)
     - Configure succeeded
    - Download succeeded
    - Started softROCcontroller
    - Prestart succeeded
    - Go succeeded
    - Data flowed for 1million events
    - Started hd_ana connecting to ER’s ET system. Very odd behavior:
      Event rate went up by a significant amount (to 1.5kHz to 2kHz from
      around 200Hz) when hd_ana was reading events from ET
      This propagated all of the way back to the ROCs.
      Stopping hd_ana caused rate to drop back down.
      Current theory is that there are too few events in the ET system created
      by the ER. The SEB is trying to grab 10 at a time, but the whole system
      has only 20. The addition of hd_ana which reads events 1 at a time 
      smoothes out the flow resulting in fewer failed requests and therefore
      fewer sleeps waiting for events to appear.

  - Attempt 5
    - Changing number of events CODA starts ET system with by editing
      COOL “Options/ERsoftROC.xml” file
    - Configure, Download, Prestart, and Go succeeded
    - Event rate behavior is the same.

This event speed-up phenomenon exposed an issue that will be addressed by the CODA group that
should help smooth out and possibly speed up the data rate.

- Testing fast starts and stops




---

This is a plain text email for clients that cannot display HTML.  The full logentry can be found online at https://logbooks.jlab.org/entry/3289248
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://mailman.jlab.org/pipermail/halld-online/attachments/20140708/3852b4fa/attachment.html 


More information about the Halld-online mailing list