[rrd-users] Re: percentile calculations

[Dan Cech]

Alex van den Bogaerdt wrote:
> On Tue, Sep 05, 2006 at 03:05:24PM -0400, Dan Cech wrote:
> 
>>>>              causing it to be incorrect.
>>> Why?
>> In this case I don't mean incorrect from a mathematical standpoint, but
>> in terms of the purpose of the report.
> 
> [snip further explanation]
> 
> OK.
> 
> Does this help:
> 
> snippet from rrdgraph.pod:
> 
>  Data and variables
>            DEF:vname=rrdfile:ds-name:CF[:step=step][:start=time][:end=time]

I did manage to make this work for a single RRD, by using code like:

DEF:rawin=$rrdfile.rrd:in:LAST:end=$now
VDEF:raw95in=rawin,95,PERCENT
CDEF:raw295in=myin,POP,raw95in,8,*
VDEF:95in=raw295in,MAXIMUM

Basically this calculates the 95th from the raw data, uses a CDEF
workaround to perform the scaling that would normally have been
performed on the DEF before the percentile is calculated, then uses the
MAXIMUM function to create a VDEF of the scaled value that I can draw on
the graph.

While this does appear to work, because it relies on access to the raw
DEF it cannot be used with data that is aggregated across multiple rrds.

It would however be great to be able to use the same syntax to specify a
start and/or end time for the VDEF, which would neatly solve the problem.

>>>> 1,2,3,4,5,6,7,8,9,10
>>>>
>>>> The 90th percentile should be 9
>>> according to what/who ?
>> The 90th percentile of the values above is 9.
> 
> Yes.  But you are not asking for the 90 percentile of these values.

I am aware of that, my initial question was whether there was any
mechanism I could use to ask for the 90th percentile of either a
specific time period or to exclude the unknowns.

>> I understand that the PERCENT function will include the 20 UNKN values
>> and produce the answer 7 which is also mathematically correct but
>> 'incorrect' from the point of view of this particular application.
> 
> Most of the times, computers do what you ask them to do, not what you
> want them to do.  This does seem to be a typical case.

Thank you for that observation, see above.

> Please try that start and end time def.  I haven't been playing with
> it for a while but if memory serves me well it does have some quircks.
> More specifically, if you have another DEF accessing the same data,
> things go wrong. This would be the exception to the rule I mentioned
> two paragraphs above.

In summary, this does seem to be one method of achieving a portion of
the desired functionality.  I didn't notice any untoward effects on the
rest of the graph in my tests, and will continue testing & looking for
other possible solutions.

Regards,

Dan

--
Unsubscribe mailto:rrd-users-request at list.ee.ethz.ch?subject=unsubscribe
Help        mailto:rrd-users-request at list.ee.ethz.ch?subject=help
Archive     http://lists.ee.ethz.ch/rrd-users
WebAdmin    http://lists.ee.ethz.ch/lsg2.cgi