pcp
[Top] [All Lists]

[Bug 1296750] incorrect interpolation across <mark> record in a merged a

To: pcp@xxxxxxxxxxx
Subject: [Bug 1296750] incorrect interpolation across <mark> record in a merged archive
From: bugzilla@xxxxxxxxxx
Date: Fri, 15 Jan 2016 08:32:26 +0000
Auto-submitted: auto-generated
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <bug-1296750-355098@xxxxxxxxxxxxxxxxxxx>
References: <bug-1296750-355098@xxxxxxxxxxxxxxxxxxx>
https://bugzilla.redhat.com/show_bug.cgi?id=1296750



--- Comment #10 from Mark Goodwin <mgoodwin@xxxxxxxxxx> ---
(In reply to Ken McDonell from comment #8)
[..]
> I think I can implement a pmCheckContinuity (suggestions for a better name
> would be appreciated) that takes two timestamps (as returned by pmFetch) and
> returns a true/false value depending on the presence of a <mark> record in
> the timestamped interval ... and I think I can do this in a way that
> involves no extra archive scanning for the common use case.  Then PMAPI
> clients processing archives that want to do rate conversion on counters and
> care could call pmCheckContinuity() after each pmFetch() and take
> appropriate action.

Hi Ken

If pmCheckContinuity() is feasible, then couldn't pmFetchArchive() do the same
for the current timestamp plus (or minus) the current pmSetMode delta? and thus
return PM_ERR_VALUE when an interpolated fetch spans a <mark>?

I have an archive that I'm about to commit to qa/archives that has a mark
record in it and all the tools seem to be able to replay it without getting any
PM_ERR_VALUE errors for a fetch that spans the mark timestamp. Both pmval and
pmdumptext check for counters going backward (and more recently pmiostat does
too) and report '?', but pmrep just faithfully reports a negative rate.

Cheers
-- Mark

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug 
https://bugzilla.redhat.com/token.cgi?t=CwSon9jhkJ&a=cc_unsubscribe
<Prev in Thread] Current Thread [Next in Thread>