| 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> |
|---|---|---|
| ||
| Previous by Date: | pcp updates - rate() for derived metrics, sysstat/sar2pcp updates, Ken McDonell |
|---|---|
| Next by Date: | Re: [pcp] Nanosecond event tracing timestamps, David Arnold |
| Previous by Thread: | pcp updates - rate() for derived metrics, sysstat/sar2pcp updates, Ken McDonell |
| Next by Thread: | pcp updates: kenj merge, qa, minor fixes, Nathan Scott |
| Indexes: | [Date] [Thread] [Top] [All Lists] |