https://bugzilla.redhat.com/show_bug.cgi?id=1296750
--- Comment #9 from Frank Ch. Eigler <fche@xxxxxxxxxx> ---
> What you're proposing is a very important change to the design assumptions
> that underpin pmFetch() and indeed the broader PCP architecture. Namely:
Yeah.
> - archives and live sources should be semantically as close as we can make
> them
> - one client can fetch different metrics at different points in time
> - pmFetch() delivers a snapshot of metric values at a single point in time
> - as a general rule temporal averaging (and rate conversion is one example
> of this) should be a client-side function (to reduce complexity, state and
> semantic uncertainty at pmcd)
Actually I think each of these properties would be preserved in the
fetch-timing-aware interpolation model.
> I think the point of interp mode is to provide values at a point in time
> that might be different to the sample times in the archive, which is subtly
> different to your suggestion of "the client doesn't want to know the ebb and
> flow of the actual underlying data".
Yeah, subtly different, but probably closer to the user/programmer
intuition.
> Critically, interp.c has no visibility to the history of pmFetch() calls, it
> operates on the state of the archive and the point in time for the current
> pmFetch().
Sure, but that is an implementation detail within libpcp. interp.c
could have access to the current context's pmSetMode time delta;
it wouldn't need to keep an actual history of prior pmFetches or their
pmResult timestamps.
> So, I'm loathe to push functionality into interp.c when I believe that
> functionality is better done in the PMAPI client.
That's a reasonable alternative, if changing pmFetch itself is
unpalatable.
> Note that all of this discussion is moot for non-counter metrics
Why so? For an SEM_INSTANT value interpolated between time [x,x+dt),
it would be reasonable to inspect all actual values in or bounding that
interval, in case e.g. the value immediately before x+dt was a random
outlier. A weighted or windowed sum over all the values could be
quite a defensible calculation too.
> [...] Then PMAPI clients processing archives that want to do rate
> conversion on counters and care could call pmCheckContinuity()a
> after each pmFetch() and take appropriate action. [...]
That would be workable too, though would mandate changes to all
existing clients, or at least all those that do rate conversion.
--
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=mGxtc48oca&a=cc_unsubscribe
|