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