[rrd-users] GPRINT produces float value although input is int

[Johan Elmerfjord]

Hi Thanos,

RRD stores all the values as floats (with decimals).

If you still use the %6lf - then you will get 6 numbers (or more). so if you print a number with 3 digits - it will adds some additional decimals.
but if you print 6-7 digit numbers - you will not get any additional decimals.

But, the interesting thing is probably how you end up with decimals - when you are inserting integers.

It can be due to several reasons.

Value Update offset:
Say that you store a value every 5 minute in RRD.
If the values are stored exactly at the 300s intervals - you would still have the same value  (195.00 as a float).
BUT, if you collect you values and put them in RRD, say with a delay of 10 seconds., then RRD will adjust this value and adjust it to what it "probably was" - at the 5 minute interval.
so if you had a value of 201 at time x+0, and inserted 195 at time x+300+10,
With a linear line between the value of time 0 and 310 from 201 to 195, you will get 195.194 at time 300.
Line equation: 201+(195-201)/310 *300=195.1938
You can also send the 5-minute timestamp in together with your value when updating a RRD to "avoid" this, but there is no real reason unless there  is a long delay between when you collect a value - and when you update the RRD file with it.

Consolidation:
There is also another reason to why you get decimals.
It has to do with consolidation that occurs when you try to display more values than you you have pixels available in your graph.
Then 2 or more values can be averaged to a point on screen - which will also be what you gprint.
More of this is explained at the following page:
http://www.vandenbogaerdt.nl/rrdtool/min-avg-max.php

RRD basically stores rates, eg events per second. and it may be that your 195-values is divided by 300second (5 min) and then get some rounding issues, but if I'm not mistaken RRD is using doubles for the data, do this shouldn't impact your data.

Regards, Johan

On Tue, 2014-05-20 at 00:30 -0700, thanos1983 wrote:


Dear S Shipway,

Thank you for your reply. I had tried any possible solution even
("GPRINT:".$in_min.": Minimum\:%6lf %S",) to remove the digits at the end
and I still was getting (195,20000000). I did not even thought to apply
("GPRINT:".$in_min.": Minimum\:%6.0lf %S",).

One final question well now I am curious when I am using 3 digits numbers
Normalisation process adds a decimal at the end. But in case that I am using
a 6 or 7 digit number with the same formation I do not get this decimal. I
do not know if my description makes sense and if there is a logical answer
to my question.

(How can I mark this answer as solved?)

Again thank you for your time and effort.



--
View this message in context: http://rrd-mailinglists.937164.n2.nabble.com/GPRINT-produces-float-value-although-input-is-int-tp7582079p7582082.html
Sent from the RRDtool Users Mailinglist mailing list archive at Nabble.com.

_______________________________________________
rrd-users mailing list
rrd-users at lists.oetiker.ch<mailto:rrd-users at lists.oetiker.ch>
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.oetiker.ch/pipermail/rrd-users/attachments/20140520/06e48700/attachment-0001.htm