Reported phase replies bigger than any shown while running

[Steve Scheid]

Summary information gives "phase-meas.replies.rate: 106457", but during the test the reply rate was never lareger than ~103760.

[Alex Rousskov (rousskov)]

The phase statistics are updated every time interval statistics are reported. Since interval stats are reported every 5 seconds, there is a 5-second precision in "current phase" selection (i.e., in the selection of the phase that gets the information about the last 5 seconds of activity).

I suspect that this optimization results in some phases getting the last ~5 seconds without any transactions while others get a 5-second worth of transactions when they just started. Notice that if you divide phase-meas.replies.size.count by (phase-meas.duration + 5), you will get the expected 103727 replies/second rate.

I cannot fully explain why this effect does not cancel itself out for the measurement phase which is surrounded by other active phases (gain a little at the beginning, lose a little at the end) so my explanation may be incorrect or there may be more going on here.

We will work on a fix.

Developer notes: The solution I would try first is to supply last interval start/stop times when starting and stopping the phases in Base::CurrentPhase. Then the stopped (previous) phase will not gain ~5 seconds without transactions and the started (current) phase will be ~5 seconds longer because it did get the transactions from the last interval.

[Dmitry Kurochkin (dmitry.kurochkin)]

Attached patch for DNS Rex v0.1.0 fixes the bug.