Yes, but only by a tenth of a unit, but enough to make me investigate. When I did testing and found that it was possible for the last 10,000 seconds to have a much higher minimum than the last 15,000 seconds I lost confidence in the function and moved to fetch-ing and parsing.
The DEF is the same, DEF:noise=noise.rrd:noise:AVERAGE . -----Original Message----- From: Alex van den Bogaerdt Sent: Friday, August 12, 2011 9:59 AM To: rrd-users@lists.oetiker.ch Subject: Re: [rrd-users] VDEF MINIMUM Are you saying that there is a discrepancy between what MIN and MAX report, vs. what can be seen on the graph? If so: are you sure you use the same (C)DEF to get min and max from? > Hi Alex, > > Thanks for that, I'll study this some more. > > For now I'm doing it the "messy" way, i.e. fetch-ing all the data into an > array, sorting it numerically ascending and then taking the first and last > values of the array as minimum and maximum values plotted on the graph. > > As I say it's not as clean as using an rrdtool function directly to > extract > min/max, but it seems to give results which correlate exactly to the > minimum > and maximum points plotted on the graphs which is the main thing. > > Thanks, > Oliver. > > -----Original Message----- > From: Alex van den Bogaerdt > Sent: Thursday, August 11, 2011 11:05 PM > To: Oliver > Cc: rrd-users@lists.oetiker.ch > Subject: Re: [rrd-users] VDEF MINIMUM > > bottom paragraph of my reply, "... the other ..." is the relevant part > then. You want to display a certain amount of RRA rows in less the amount > of pixel columns, so RRDtool is going to do some on the fly consolidation. > > Try an end time which is n*60, try to display 400*60 seconds, do so in 400 > pixel columns. > GPRINT last, min, average, max. > Now try the same, except that you display 400*30 seconds. > > This part of the tool has had more than its fair share of problems in the > past, I seem to recall an off by one error or two, and other problems. > There could be differences between the various RRDtool versions, but all > versions will have some form of on the fly consolidation, where multiple > RRA rows will be combined into one pixel row. > > Once you understand the relatively easy n*30 vs. n*60 case, try to figure > out what the tool does with n*40, n*50 and so on. > > GPRINTing the time component of the first and last sample on the graph may > also be interesting. > > cheers, > Alex _______________________________________________ rrd-users mailing list rrd-users@lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
