Reported phase replies bigger than any shown while running
Bug #720185 reported by
Steve Scheid
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | ||
---|---|---|---|---|---|---|
Rex | Status tracked in 0.1 | |||||
0.1 |
Fix Committed
|
Undecided
|
Dmitry Kurochkin |
Bug Description
Summary information gives "phase-
Changed in rex: | |
assignee: | nobody → Dmitry Kurochkin (dmitry.kurochkin) |
To post a comment you must log in.
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.