[rrd-users] RRD PERCENT question (95 percentile)

[Alex van den Bogaerdt]

>>> http://toonk.nl/rrdtest/
>> Please dump to xml. Without actually promising, I may have a look friday 
>> or
>> later.
>
> I added the output of :
> rrdtool dump deviceid11_XXX_Transit.rrd >deviceid11_XXX_Transit.xml
> to the same directory.


First of all:
My rrdtool version gets one line too many at the end of rrdtool fetch, yours 
gets one line too many at the beginning.
There have been off-by-one errors during development, including but not 
limited to the examples just mentioned.

Here's how I think it should work:
An interval has a begin, an end and a duration. The intervals are named by 
their end time timestamps , their duration is defined from the rrd 
properties. The starttime follows from these properties.

The interval named 1271894700 and with duration 300 seconds is covering the 
time range from 1271894400 to 1271894700.

You ask for --start '1271894400' --end '1272240000' which is 345600 seconds. 
At 300 seconds per interval this means 1152 intervals. Your file OUT_RAW 
should then be 1054 lines, starting with a header of two lines, the 3rd line 
should be timestamp 1271894700 and the last line should be timestamp 
1272240000.
The interval with timestamp 1271894400 should not be there. It covers time 
range 1271894100 to 1271894400.
Similarly the interval with timestamp 1272240300 should not be there (1.2.30 
does)

A quick and dirty solution: --start '1271894401' --end '1272239999'

Second problem:
You define a width of 700. That is not just pixels, it is also intervals. 
RRDtool will do some on the fly consolidation because you try to fit 1054 
intervals in 700.  That's why I altered width to be 1052 in the script.

I added two lines to your rrd95.sh script. Now it not only reports the time 
for FirstDate and LastDate, it also reports the corresponding rates. 
PRINT:FirstDate:"rate %lf" and PRINT:LastDate:"rate %lf"

Then I verified those rates, making sure that they are the same as was in my 
OUT_RAW file (named OUT3):
$ tail +3 OUT3 | head -1; tail -1 OUT3
1271894700: 5.2195528693e+05 1.1903315295e+06
1272240000: 1.2896079369e+06 3.1699193830e+05

from rate 4175642.295440 / 8 = 521955.28693
to rate 10316863.495200 / 8 = 1289607.9369

These rates are correct.

Then I split my OUT_RAW file using awk, and sort it numerically:
tail +3 OUT3 | awk '{printf("%.10lf\n",$2);}' | sort -n > ds0.sort
tail +3 OUT3 | awk '{printf("%.10lf\n",$3);}' | sort -n > ds1.sort

print line 1094 from both files:
$ sed -n 1094p <ds0.sort ; sed -n 1094p <ds1.sort
1140469.7216000000
1094912.3171000001

Either multiply by 8, or alter rrd95.sh to not multiply by 8, and the 
numbers match.
(by the way... multiplying by 8 was not necessary to investigate the problem 
and makes debugging this harder, because the numbers in OUT_RAW are not 
multiplied by 8. Next time please don't)

I leave it up to you to let verify95.pl show the same.

HTH
Alex