Project

General

Profile

Idea #4430

Provide information on prescale factor or rate in the fraction of events that are passed to the online monitoring

Added by Kurt Biery almost 6 years ago. Updated about 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
07/25/2013
Due date:
% Done:

0%

Estimated time:
Duration:

Description

I'm filing this issue to capture some of the recent discussion on the subject of providing information on what fraction of the full event stream are sent to the online monitor...

Alessandro asked if the initial multi-aggregator model for sending events to a dedicated online monitoring process would provide information on what fraction of the events were seen by the monitoring code. It would not, and other, more sophisticated, models would also not provide that. So, the question came up "is this needed?" The need seems to be the ability to calculate phototube trigger rates.

More details in a minute...


Related issues

Related to artdaq - Idea #5985: Redesign the model that is used to provide events to online monitoringRejected2014-04-21

History

#1 Updated by Kurt Biery almost 6 years ago

One way to provide a well-determine fraction of the events to the online monitoring application/modules is to prescale the events and provide the prescale value to the onmon modules. Operationally, though, prescaling seems like it could be a pain. Tuning a prescale so that the online monitoring application doesn't cause backpressure but doesn't wait long times for events seems like a lot of work. And a small increase in the trigger rate during a run could make the prescale that was set at the beginning of the run obsolete quite quickly.

A better way to provide events to online monitoring applications is to have them request events whenever they are ready. In this model, online monitoring applications get the maximum rate of events that they can handle. Of course, the prescale factor is not well-defined in this case. But, maybe there would be a way to put information into the data stream about the number of events that have been skipped.

Another suggestion (from Alessandro) would be to provide a specified number of events per second. As long as these events were consecutive, they could be used to help determine a rate...

#2 Updated by Kurt Biery about 5 years ago

  • Status changed from New to Closed

Closing this issue in favor of #5985.



Also available in: Atom PDF