Re: [rrd-users] can't sanity-check rrdtool with sample data ...

Gore Jarold wrote:

>So this is the other problem - and I'll just make the
>question easy:
>
>If my update command is:
>
>rrdtool update hits.rrd 1141286400:1 1141372800:10
>1141459200:10 1141545600:12 1141632000:12
>1141718400:12
>
>and I want my output with fetch to give me:
>
>1,10,10,12,12,12
>
>Then what is wrong with my 'rrdtool create' statement:

Nothing, it's your update statements that are wrong.

>rrdtool create hits.rrd --start 1141200000 --step
>86400 DS:hits:GAUGE:172800:0:U RRA:MAX:0.5:1:3650
>
>because right now, instead of the 1,10,10,12,12,12
>that I put in, I am getting:
>
>1141257600: 1.0000000000e+00
>1141344000: 7.0000000000e+00
>1141430400: 1.0000000000e+01
>1141516800: 1.1333333333e+01
>1141603200: 1.2000000000e+01
>1141689600: 1.2000000000e+01
>
>when I fetch it back out ... (1,7,10,11.3,12,12)

Notice that the timestamps are different - there's 8 hours difference
between the boundaries of the stored step intervals and the points
you feed in data for.
http://www.vandenbogaerdt.nl/rrdtool/process.php explains the
normalisation that goes on, but in this case it means that for every
value you feed in, 1/3 goes into one bin, the other 2/3 goes into a
different bin.

See what goes into the different bins
1/3 of unknown, plus 2/3 of 1 over 2/3 of the time = a rate of 1
1/3 of 1 plus 2/3 of 10 = 7
1/3 of 10 plus 2/3 of 10 = 10
1/3 of 10 plus 2/3 of 12 = 3.3 + 8 = 11.3
1/3 of 12 plus 2/3 of 12 = 12

It would help you visualise this if you plot the points of the
updates and the boundaries of the 'bins' on the time axis as is shown
on the web page above.

Fundamentally the problem is that you are thinking of an RRD like a
traditional database where what you get out is what you put in - it
isn't. RRD is designed to normalise data to fit specific timeslots so
in the general case what you get out is a normalised (and usually
consolidated) version of what went in.


This isn't the first time this time issue has come up, the tools
don't support 'daily' samples over anything other midnight-midnight
UTC which is not always what people in other timezones want. However,
I suspect that modifying the software to support a 'zero point'
offset from unix epoch/UTC would be non-trivial.

_______________________________________________
rrd-users mailing list
rrd-users@lists.oetiker.ch
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users