Reported phase replies bigger than any shown while running

Bug #720185 reported by Steve Scheid on 2011-02-16
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Status tracked in 0.1
Dmitry Kurochkin

Bug Description

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

Steve Scheid (steve-scheid) wrote :
Alex Rousskov (rousskov) wrote :

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.

Changed in rex:
status: New → In Progress
Changed in rex:
assignee: nobody → Dmitry Kurochkin (dmitry.kurochkin)

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments