How PM calculates
DX NetOps Performance Management: Any version
"Hourly and daily rollup performs the percentile calculation on the polled rate data. Weekly rollup performs the percentile calculation on the results of the daily rollups."
DX NetOps Performance Management uses Vertica's PERCENTILE_CONT(0.90) function.
An inverse distribution function where, for each row, PERCENTILE_CONT
returns the value that would fall into the specified percentile among a set of values in each partition within a window. For example, if the argument to the function is 0.5, the result of the function is the median of the data set (50th percentile). PERCENTILE_CONT
assumes a continuous distribution data model. NULL
values are ignored.
PERCENTILE_CONT
computes the percentile by first computing the row number where the percentile row would exist. For example:
If row‑number
is a whole number (within an error of 0.00001), the percentile is the value of row row‑number
.
Otherwise, Vertica interpolates the percentile value between the value of the CEILING(row‑number)
row and the value of the FLOOR(row‑number)
row. In other words, the percentile is calculated as follows:
( CEILING( row‑number) - row‑number ) * ( Value of FLOOR(row‑number) row )
+ ( row‑number - FLOOR(row‑number) ) * ( Value of CEILING(row‑number) row)
If the percentile value is 0.5, PERCENTILE_CONT
returns the same result set as the function MEDIAN
.
Do not use the MS Excel PERCENTILE.EXC.
Hourly percentile is calculated from the polled (every 5 min) raw data for the hour.
We do rollups/baselining from 00:00:01 to 01:00:00 and tag that as 01:00:00.
The Percentile 90 value now matches:
Daily rollup performs the percentile calculation of the raw data for the day (polled data).
BPS In is calculated each poll cycle, to record how many BPS In for 5 mins.
90% would be PERCENTILE_CONT(0.90) for the hour of BPS In values, or day of BPS In values.
BPS In is just another metric like Bits In, Utilization In, etc
So for this view, if the resolution is Hourly, then it's doing 90% of all hourly data points during the time range.
Or it could be going 90% of all the hourly 90% values... probably this way... you would need to enable RIB debug to see the actual call to DA for the 90% call.