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: Thu, 14 Jan 2016 05:52:24 +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 #5 from Ken McDonell <kenj@xxxxxxxxxxx> ---
This is pretty subtle, but I don't think there is an error in interpolation
here.  We may have a (different? bigger?) problem associated with rate
conversion.

Consider this sequence of values in an archive

time value
t0   n/a
t1   v1
t2   v2
t3   <mark>
t4   v4
t5   v5

Now consider pmFetch requests at time t for the following cases:

t0 <= t < t1    no value available
t1 <= t < t2    value based on v1 and v2
t2 <= t < t4    no value available
t4 <= t < t5    value based on v4 and v5

This is both correct and what the current implementation does.  It is also the
same behaviour that libpcp has always exhibited, so there is no regression.

The problem would be most evident in cases where the <mark> record is
associated with a pmcd restart, rather than the daily cron archive rotation,
and the reporting interval from the client is long in relation to the pmlogger
sampling intervals.

Now consider an application that is doing rate conversion on the values for
consecutive samples from the example above.  There is no problem when
consecutive samples are both in either of the regions t0 <= t <t4 or t4 <= t <
t5.  The problem comes when the consecutive samples come from t1 <= t < t2 AND
t4 <= t < t5 ... in this case both values are well defined from an
interpolation perspective, but the resultant rate calculation is bogus.

A solution here is not within the realm of pmfetch() (and hence nothing to do
with interp.c) as there are two pmFetch() calls involved, both of which return
valid and well-defined values.

Seems like we're going to need some additional functionality here ... perhaps a
real pmlogreduce that converts these counter metrics to rates and could
accommodate <mark> records and "minimal interval coverage" to decide if there
is a sensible representative value for an interval, and/or a new API function
to allow PMAPI clients using archive contexts to determine if the archive data
is continuous from time tx to time ty.

Not sure what to do with this bug now.

-- 
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=ouS8wihlJV&a=cc_unsubscribe
<Prev in Thread] Current Thread [Next in Thread>