[rrd-users] VDEF min/last incorrectly show NaN
kubicaryan at yahoo.com
Sat Mar 19 17:40:30 CET 2011
That trick no longer seems to work:
that's 360 pixels, 2880 datapoints with presumably 8 datapoints per pixel. I can
even add an entire 3 hours to the end of the DEF: and have the graph still not
display the extra data and the min/last still show 0 (or rather that last pixel
This is coming from an RRD that has step 60 for 3 months and step300 for 2years.
Data graph is for yesterday:
$ perl -e 'print localtime(1300491600) . "\n";'
Fri Mar 18 16:40:00 2011
So 'not enough data' isn't the reason either.
I'm debating using ADDNAN in the 'zero calculations' and getting rid of the
nan->0 conversion; it probably will correct for more of the problem; but there's
still something going weird with nan and that last pixel that I'd much rather
correct for properly. If there was a real formula for width and fetching data
to make sure that last pixel had data I would prefer to do that.
It's too bad MULTIPLYNAN and SUBTRACTNAN don't exist. :-) ADDNAN alone isn't
sufficient; especially with more complex rpn.
From: Alex van den Bogaerdt <alex at vandenbogaerdt.nl>
To: rrd-users at lists.oetiker.ch
Sent: Sat, March 19, 2011 3:27:23 AM
Subject: Re: [rrd-users] VDEF min/last incorrectly show NaN
----- Original Message -----
From: "Ryan Kubica" <kubicaryan at yahoo.com>
To: <rrd-users at lists.oetiker.ch>
Sent: Saturday, March 19, 2011 8:29 AM
Subject: [rrd-users] VDEF min/last incorrectly show NaN
> I'm trying to resolve an issue with rrd graphing which has the min/last
> showing NaN (in my example case below they show zero since I convert NaN
> to 0.)
"min" should ignore NaN, so let it work on data you did not yet do that
> What's the trick to getting a graph to always have data available in the
> pixel of the graph so min/last will have data for the legend?
The trick used to be (don't know if it still works or not) to match start
time, end time and duration with your RRA.
Each pixel should have a whole number of CDPs (RRA buckets), and not just
any of them, you would need to match it so that if you would have an RRA
that could be used to display one CPD per pixel, it would work. So if "a
whole number" is 1, you should have an RRA that covers the whole time range
you're asking for, with boundaries exactly on start and end time, and with
graph_width multiplied by time_per_CDP equals end time - start time.
Simplest test case:
"steps" is the amount of time in each CDP
"n" is any integer
let end time (in unix since epoch time) be n * steps
give the graph a certain width in pixels
start time is end time - (graph_width * steps)
> I have a graph generator that accepts an end_time; this end_time is
> already in
> the past, new records since exist, so it's not an issue of the last_update
> the last record I'm choosing.
> It seems to be correlated to graph width and time frame (start <-> end).
> As an example: step 60, two different widths, 287 pixels and 288 pixels
> for a 2
> day period (2880 1 minute datapoints.)
> (shows zero)
If you want to show 2880 CDPs in 288 pixels, RRDtool has to consolidate 10
CDPs on the fly. Your end time should be n*10*60. It is, thus there is no
need for RRDtool to "massage" anything,
First thing to do is to make sure there is enough data in your RRA. If not,
maybe another RRA, covering more time, is a better match to what you ask,
and RRDtool rightfully selects that RRA.
In your case this means the RRA should have at least 2880 CDPs, plus the
amount of CDPs needed to cover the time between 1300491600 and 'now'.
> The interesting part is that the zero's show until 575 pixels - which is
> coincidentally close to 287*2+1.
Another reason to look for problems with the size of your RRA with 1-minute
rrd-users mailing list
rrd-users at lists.oetiker.ch
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rrd-users