Bug#180283: rrdtool: CDEF function PREV(name) timesteps far too mauch

2015-09-08 Thread Goswin von Brederlow
On Wed, Aug 26, 2015 at 09:26:42AM +, Jean-Michel Vourgère wrote:
> Control: tags -1 +moreinfo
> Control: noowner -1
> 
> Hello Goswin
> 
> I'm cleaning up the rrdtool bug list, and I dig a bit into this one
> submitted back in 2003!
> https://bugs.debian.org/180283
> 
> I'm sorry no one from the Debian project answered you since then.
> 
> 
> You listed the cgi source, but not the actual command used to create the
> rrd database.
> A cgi only works if a database is created first. This is almost
> impossible to answer to your bug report without that information.
> 
> I can only assume you are (were) using code from the original donitor
> whose source code is available at http://sourceforge.net/projects/donitor/
> There, in file /sbin/update_rrd.pl, in function create_rrd, the step is
> set to 120 seconds, and the heartbeat to 240 seconds:
> 
> > rrdcreate esel.rrd --step 120 DS:workload_down:GAUGE:240:U:U 
> > DS:workload_up:GAUGE:240:U:U DS:overhead_in:GAUGE:240:U:U 
> > DS:overhead_out:GAUGE:240:U:U DS:connections:GAUGE:240:U:U 
> > DS:ds1:GAUGE:240:U:U DS:ds2:GAUGE:240:U:U RRA:AVERAGE:0.5:1:360 
> > RRA:AVERAGE:0.5:4:360 RRA:AVERAGE:0.5:16:360 RRA:AVERAGE:0.5:64:360 
> > RRA:AVERAGE:0.5:256:360 RRA:MIN:0.5:4:360 RRA:MIN:0.5:16:360 
> > RRA:MIN:0.5:64:360 RRA:MIN:0.5:256:360 RRA:MAX:0.5:4:360 RRA:MAX:0.5:16:360 
> > RRA:MAX:0.5:64:360 RRA:MAX:0.5:256:360
> 
> Actually, your variable names are different (urate3 versus ds2) but I'll
> assume a moment you were using these settings.
> 
> This means you have:
> - A 2 minutes resolution for 12 hours (meaning if last value is "now",
> then first value is now-11h58)
> - A 8 minutes resolution for 48 hours
> - A 32 minutes resolution for 8 days
> - ...
> 
> 
> Also, you defined:
> CDEF:sdrate3=PREV(sdrate3)
> which is impossible. PREV must be applied to another value, not to
> itself! This may be the source of the problem.
> I'll assume you meant sdrate3=PREV(drate3)
> 
> 
> I may have been able to reproduce the issue, but not just for sdrate3,
> all the data is showing a 8 minutes resolution.
> 
> Therefore, it seems normal that PREV() is 8 minutes earlier. Is it
> possible you did not notice that everything has a 8 pixel horizontal
> resolution but only that the two lines were 8 pixels apart?
> 
> As far as I can tell, x=PREV(x) is not working any more, it doesn't show
> weird things and does not loop nor overflow any more. This may have been
> fixed upstream.
> 
> 
> Now why do we have a 8 minutes resolution?
> 
> It tried different values for --start.
> --start 'end-12h00' yield a 8 minutes resolution
> --start 'end-11h00' yield a 8 minutes resolution
> --start 'end-10h59' yield a 2 minutes resolution
> 
> I may dig a bit in that part. There may be two issues there. A time zone
> one (I'm UTC+1) and an interval one...
> 
> If you still have the data, know the way you created the rrd file,
> and/or how it's filled, it will help pin point that issue.
> 
> Thanks
> 
> -- 
> Nirgal

Sorry, after 12 years I have no idea how I did set that up anymore nor
do I still run it.

MfG
Goswin



Bug#180283: rrdtool: CDEF function PREV(name) timesteps far too mauch

2015-08-26 Thread Jean-Michel Vourgère
Control: tags -1 +moreinfo
Control: noowner -1

Hello Goswin

I'm cleaning up the rrdtool bug list, and I dig a bit into this one
submitted back in 2003!
https://bugs.debian.org/180283

I'm sorry no one from the Debian project answered you since then.


You listed the cgi source, but not the actual command used to create the
rrd database.
A cgi only works if a database is created first. This is almost
impossible to answer to your bug report without that information.

I can only assume you are (were) using code from the original donitor
whose source code is available at http://sourceforge.net/projects/donitor/
There, in file /sbin/update_rrd.pl, in function create_rrd, the step is
set to 120 seconds, and the heartbeat to 240 seconds:

 rrdcreate esel.rrd --step 120 DS:workload_down:GAUGE:240:U:U 
 DS:workload_up:GAUGE:240:U:U DS:overhead_in:GAUGE:240:U:U 
 DS:overhead_out:GAUGE:240:U:U DS:connections:GAUGE:240:U:U 
 DS:ds1:GAUGE:240:U:U DS:ds2:GAUGE:240:U:U RRA:AVERAGE:0.5:1:360 
 RRA:AVERAGE:0.5:4:360 RRA:AVERAGE:0.5:16:360 RRA:AVERAGE:0.5:64:360 
 RRA:AVERAGE:0.5:256:360 RRA:MIN:0.5:4:360 RRA:MIN:0.5:16:360 
 RRA:MIN:0.5:64:360 RRA:MIN:0.5:256:360 RRA:MAX:0.5:4:360 RRA:MAX:0.5:16:360 
 RRA:MAX:0.5:64:360 RRA:MAX:0.5:256:360

Actually, your variable names are different (urate3 versus ds2) but I'll
assume a moment you were using these settings.

This means you have:
- A 2 minutes resolution for 12 hours (meaning if last value is now,
then first value is now-11h58)
- A 8 minutes resolution for 48 hours
- A 32 minutes resolution for 8 days
- ...


Also, you defined:
CDEF:sdrate3=PREV(sdrate3)
which is impossible. PREV must be applied to another value, not to
itself! This may be the source of the problem.
I'll assume you meant sdrate3=PREV(drate3)


I may have been able to reproduce the issue, but not just for sdrate3,
all the data is showing a 8 minutes resolution.

Therefore, it seems normal that PREV() is 8 minutes earlier. Is it
possible you did not notice that everything has a 8 pixel horizontal
resolution but only that the two lines were 8 pixels apart?

As far as I can tell, x=PREV(x) is not working any more, it doesn't show
weird things and does not loop nor overflow any more. This may have been
fixed upstream.


Now why do we have a 8 minutes resolution?

It tried different values for --start.
--start 'end-12h00' yield a 8 minutes resolution
--start 'end-11h00' yield a 8 minutes resolution
--start 'end-10h59' yield a 2 minutes resolution

I may dig a bit in that part. There may be two issues there. A time zone
one (I'm UTC+1) and an interval one...

If you still have the data, know the way you created the rrd file,
and/or how it's filled, it will help pin point that issue.

Thanks

-- 
Nirgal