cet-is

In this note I will address 2 things.

1)
What behaviour do I want for the "Starting the nth event" heartbeat message.

2)
What behaviour do I want to for other sorts of messages.

Here we go:

1)
The behaviour that I would like to see is as follows. The behaviour is characterized by a single run-time parameter. The example below gives the example for the parameter having a value of 3. In this case I would like to see event heartbeat messages on the following events:

1, 2, 3
10, 20, 30
100, 200, 300
1000, 2000, 3000
10000, 20000, 30000
and so on.

I would also be happy with minor variations, such as:

1, 2, 3
11, 21, 31
101, 201, 301
1001, 2001, 3001
and so on.

An obvious question arises about what to do if I pick a number greater than 9, so that the "single digit" messages overflow into the "2 digit" messages. I don't care - just so long as nothing breaks.

The spirit is that I want to see a regular heartbeat when I am debugging a smallish number of events, which I would normal do interactively. But once I start running a large numbers of events, I don't want the log file to fill up with heartbeat messages ( and I don't want to need to change this part of the configuration between debugging and production running ).

I said that the algorithm was characterized by a single parameter but there is an implicit second parameter - this is all based around powers of 10. As far as I am concerned this can be fixed and does not need to be run-time configurable.

Another run-time configurable parameter might be the power of ten at which the backoff stops. For example I might wish to get messages every 10000 events indefinitely.

2)
About other error messsages, such as "Warning: Too many straw hits in this event", I can live with the above behaviour but my preferred behaviour is that I would get the first N such messages and no more after that, where N is a run-time configurable parameter. I would also like to have a table at the end of job that prints out how often each message appeared (maybe I only get to count on a per category, not a per message basis ).

The spirit here is that I am a looking for events to debug I can run a job to get a printed list of interesting event numbers - then can do a second pass with diagnostics turned on just for those events. The table at the end is useful for making time series plots in order to look for trends.