[rrd-users] Last value always nan
Alex van den Bogaerdt
alex at ergens.op.het.net
Tue Sep 4 17:44:57 CEST 2007
On Tue, Sep 04, 2007 at 05:37:27PM +0200, Michael Jürgens wrote:
> > Solution:
> >
> > Integer divide 1188916748 by your step size (60?), then multiply
> > by the same amount. The result is 1188916740. Use that as end time.
> >
>
>
>
> > /usr/local/rrdtool/bin/rrdtool fetch
> > /home/mrtg/data/dolly.log4j.warn.rrd AVERAGE -s 1188919920 -e
> > 1188919920
> > ds0 ds1
> >
> > 1188919980: nan nan
>
> but
>
> > /usr/local/rrdtool/bin/rrdtool fetch
> > /home/mrtg/data/dolly.log4j.warn.rrd AVERAGE -s 1188919919 -e
> > 1188919920
> > ds0 ds1
> >
> > 1188919920: 0.0000000000e+00 0.0000000000e+00
> > 1188919980: nan nan
>
> and
>
> > /usr/local/rrdtool/bin/rrdtool fetch
> > /home/mrtg/data/dolly.log4j.warn.rrd AVERAGE -s 1188919919 -e
> > 1188919919
> > ds0 ds1
> >
> > 1188919920: 0.0000000000e+00 0.0000000000e+00
>
> So it should be "int(ts/60)*60-1" - right?
Erm... yes and no.
This has been discussed in the past (several times) and the conclusion
was:
* A timestamp itself has no duration.
* Intervals (in rrdtool) are defined by a duration and an end time.
* If you want information *ending* at 1188919920, you are NOT asking for
the interval *starting* at 1188919920.
In other words: time 1188919920 "belongs to" interval 1188919919..1188919920.
But apperently one of these is true:
-1- you are using a version which still contains the bug, and you should
upgrade
or
-2- the bug was introduced again, and should be fixed again
or
-3- Tobi changed his mind, and I'm not aware of it
Several off-by-one errors will result from such mistakes. Try
showing a huge spike at the very end of your time interval, and
compare with output of GPRINT.
In the mean time: yes, int(ts/60)*60-1 will work. But it should not
be necessary.
HTH
--
Alex van den Bogaerdt
http://www.vandenbogaerdt.nl/rrdtool/
More information about the rrd-users
mailing list