Online QA Rate Limitations

Some interest has been expressed to obtain increased statistics for at least some quantities shown in the Online QA plots. We will first review what is currently available, and then discuss approaches for change.

CURRENT SET-UP

  • The DAQ group makes events available in the event pool. These events typically arrive at a rate of nearly 10 Hz, and are controlled to be specific (generally minbias-like, full-detector) triggers.
  • The Online QA program evpServer digests this data by grabbing the most recent event in the pool whenever it finishes with an event (pausing if nothing newer than the just-processed event is available). Processing minbias-like pp events on the current 2.4 GHz dual-CPU EVP machine (see Appendix for specs) takes approximately 1 second (1 Hz), but the code is not written and compiled to be parallelized.

POSSIBILITIES

  1. Data Selectivity:
    • A different mix of events can be fed into the event pool. For example, events with only fast detectors can be processed at a rate of about ? Hz by evpServer (still under investigation). This would be a very easy way to increase statistics for fast detectors, though the increase would still be rather mild.
    • Online QA could selectively process only portions of each event for a large fraction of the incoming events. Again, not too much effort, and mildy helpful for a few detectors.
  2. Parallelism:
    • The evpServer code could be re-written and compiled for multi-threading/parallel-processing. This would be a major effort (rough estimate of 2-3 FTE-months, depending on the developer's familiarity with the topics), but would provide access to the multiple CPUs already available on the EVP machine (though evpServer is not the only process running on this machine and it would need to compete for resources). This would be able to benefit all detectors with rate increases of perhaps x2 with the current EVP machine.
    • Multiple instances of evpServer could run either on the same EVP machine, or even on multiple machines. This is likely easier to implement than the multi-threading/parallel-processing approach withing a single program.
  3. Hardware:
    • New hardware is becoming available with 16 or more cores. Development along the line of parallelism on a single machine could lead to an order of magnitude increase in evpServer processing rates.
    • Running evpServer on multiple machines obviously implies additional computers would need to be bought.
    • There is very little room currently for hardware with increases CPU speeds (e.g. 3 GHz). Simply replacing the current EVP machine with a dual 3 GHz CPU machine would likely yield only marginal gains (much less than x2) in processing rates. Additional hardware only helps if parallelism is developed.
  4. Event Pool Filling Rates:
    • Unless the above-described techniques of data selectivity and/or parallelism are employed, the current event pool filling rate is not a limiting factor.
    • Additionally, the DAQ group believes that the current setup can handle something like 50-75 Hz of full-detector events through merely reconfiguration (almost no additional work). It is unlikely that such a rate would be limiting on a single machine without combining data selectivity and parallelism techniques together.

Appendix: Specs of current EVP machine

2 x 2.4GHz Xeons with Hyperthreading
2GB of memory (perhaps PC2400)
~1+ TB of disk (6x250GB disks in a RAID 5 array)
4 NICs, 2 presently in use (Gb/sec from DAQ, 100MB/sec over "starp")