Re: event ratio patch updated

[Martin Pala]

Jan-Henrik Haukeland wrote:
> I have only browsed through the patch and it looks fine by me,  although 
> I'm not quite sure what is going on with the Event.state_map  
> bit-flicking :-)

The state is kept in in the bitmap which workes similar to the 
ringbuffer - it is rotated to the left by one bit automaticaly when the 
new event appeared and the current state (failed or passed) is set to 
the right-most bit.

Then the bitmap is compared whether the state change can be triggered 
(i.e. passed->failed ot failed->passed). The testing rule ("x times 
within y cycles") says how many occurences during how many cycles are 
needed to change the state and apply the action (independently for 
failed and passed state change). The <cycles> limit defines how many 
bits are compared from the right to the left. Then the appropriate count 
of bits (i.e. last corresponding cycles state) are compared. Just bit 
rate of the same state as current event is counted. When the final rate 
corresponds to the rule and the current service state is inverse, the 
state is changed.

It is quite simple and self-managing :)


> Since you use a long long (could uint64_t be used  
> instead?) does this mean that there are only room for 64 failed/ passed 
> events?

Right. The bitmap is adaptive - depending on how large the 'long long' 
type is on given architecture, then the corresponding cycles count 
history are kept.

The parser checks for 'long long' size vs. cycles count in the rule and 
reports the corresponding maximal value when the cycles count is greater 
then can be described by the 'long long' bitmap.

Even on usual 32-bit architectures, last 64 cycles are available, which 
is sufficient i think ;)

> It should be more than enough but should maybe be  documented 
> (if I'm right).

OK, i will add some notice to the documentation.


Martin