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

[Ryan Kubica]

That trick no longer seems to work:

http://stalemate.vendetta.com:7171/waterware?a=g&ds=icmpMus&n=tuolumne&e=1300491600&w=360


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 
is nan.)

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.


-Ryan




________________________________
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 
> 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
>7
> (correct)
>http://stalemate.vendetta.com:7171/waterware?a=g&ds=loadavg1&n=tuolumne&e=1300491600&w=288
>8
> (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. 

_______________________________________________
rrd-users mailing list
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/20110319/d0f2eef0/attachment.htm