pcp
[Top] [All Lists]

Re: [pcp] Floating point problem

To: Martin Spier <mspier@xxxxxxxxxxx>
Subject: Re: [pcp] Floating point problem
From: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Date: Tue, 05 Aug 2014 11:04:01 +1000
Cc: Amer Ather <aather@xxxxxxxxxxx>, Coburn Watson <cwatson@xxxxxxxxxxx>, Brendan Gregg <bgregg@xxxxxxxxxxx>, pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <53D6CE6A.8030309@xxxxxxxxxxxxxxxx>
References: <CAEp4+dU2kE9JJztBPc=N5oSyoEyBvN5Of19rohC3DxXGeomuRw@xxxxxxxxxxxxxx> <033501cfa8a4$fd091ed0$f71b5c70$@internode.on.net> <CAEp4+dUH6fEQ2E=o5O2q8LKfR2xUypM-AeOwQhWy9sEntvO-AQ@xxxxxxxxxxxxxx> <53D6CE6A.8030309@xxxxxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0
On 29/07/14 08:27, Ken McDonell wrote:
...
The options are ...

...

3. Extend the derived metrics support.  We already have delta() which
can be applied to counter metrics and returns the difference in value
between one pmFetch and the next.  This is closer to the semantics
Martin needs, but does not include the divide by delta(timestamp) part.
  I could add rate() as a new intrinsic function for derived metrics
that does the rate conversion.

With option 3. the derived metric definitions would be something like ...

kernel.pct.cpu.user = 100 * rate(kernel.all.cpu.user) / hinv.ncpu

I have checked in the changes to implement option 3.

It seemed generally useful and not a big change, independent of the Netflix folk investigating the option 2. route.

<Prev in Thread] Current Thread [Next in Thread>
  • Re: [pcp] Floating point problem, Ken McDonell <=