Hi, Ken -
kenj wrote:
> [...]
> The expressions above will produce exactly the floating point
> precision problem Martin has observed.
>
> The options are ...
>
> 1. Revisit the design specs for pmwebd and see if it makes sense for
> this daemon to be performing per-client rate conversion (so taking on
> some of the role of a PMAPI client, like pmie, pmval, pmchart,
> pmdumptext, ... [...]
This is possible (and can be encoded in a backward-compatible way).
As pmwebd is a PMAPI bridge, it is both a client and a server.
Indeed, this calculation may not be too difficult to code up in this
code, benefitting as it does from C++ and readily available context
usage statistics. (Just for completeness, I'd like to re-mention the
alternative of having libpcp do this, so this many individual PMAPI
clients don't have to.)
> 2. Push the rate conversion arithmetic out the the pmwebd clients
> [...]
This is possible too, but we may need to have the derived-metrics
machinery preserve numerical precision (and not devolve to floating
point numbers prematurely).
> 3. Extend the derived metrics support [with rate conversion intrinsics]
This is possible too.
- FChE
|