[rrd-users] VDEF min/last incorrectly show NaN

[Alex van den Bogaerdt]

----- 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 
> values
> 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 
conversion for.

> What's the trick to getting a graph to always have data available in the 
> last
> 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 
> being
> 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.)
>
> http://stalemate.vendetta.com:7171/waterware?a=g&ds=loadavg1&n=tuolumne&e=1300491600&w=287
> (correct)
> http://stalemate.vendetta.com:7171/waterware?a=g&ds=loadavg1&n=tuolumne&e=1300491600&w=288
> (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 
slots.