[rrd-users] peak after NaN?

[Tobias Oetiker]

Hi Nuno,

Today Nuno Gonçalves wrote:

> root at OpenWrt:/home# rrdtool create met.rrd --step 60
> DS:pressure:GAUGE:90:0:1100 RRA:AVERAGE:0.5:1:10080
> root at OpenWrt:/home# rrdtool update met.rrd N:998
> root at OpenWrt:/home# rrdtool update met.rrd N:998
> root at OpenWrt:/home# rrdtool update met.rrd N:997
> root at OpenWrt:/home# rrdtool update met.rrd N:998
> root at OpenWrt:/home# rrdtool update met.rrd N:998
> root at OpenWrt:/home# rrdtool update met.rrd N:998
> root at OpenWrt:/home# rrdtool fetch met.rrd AVERAGE -s -300
>                        pressure
>
> 1239669900: nan
> 1239669960: 9.9704365867e+02
> 1239670020: nan
> 1239670080: nan
> 1239670140: 9.7894216081e+02
> 1239670200: nan
> root at OpenWrt:/home# rrdtool
> RRDtool 1.2.30  Copyright 1997-2008 by Tobias Oetiker <tobi at oetiker.ch>

voila, as I said .... the problem is, that 'unknown' time is
calculated by the second ... but data updates coming with N: are
exact to the milli second ... hence there is a jitter as you move
from the unknown to the known state ... a step is only considered
valid if at least 50% of the time is "known"

in the worst case this means, you have a value of ~1000 for ~29 seconds
averaged over 30 seconds ... hence 1000/30*29 = 966.66

you can avoid this problem by sending your updates in with 1 second
precision and not N: at the price of some jitter in the normal case
... but since you are looking at a gauge value, this should not be
a problem.

the problem exists because subsecond precision for updates was
introduced without changeing the data format, hence unknown seconds
is not subsecond aware ...

hope this helps

cheers
tobi



>
> 2009/4/13 Tobias Oetiker <tobi at oetiker.ch>:
> > Today Nuno Gonçalves wrote:
> >
> >> 2009/4/13 Tobias Oetiker <tobi at oetiker.ch>:
> >> > yes, because it is over the maximum periode duration, so the next
> >> > sample will establish the start of the new periode ...
> >>
> >> I've done some tests and I concluded that the RRA timespan is always
> >> between two points that verify TIME%(rrd_step*rra_steps)==0. Is this
> >> correct? What will the sample time decide about the periode in this
> >> case...?
> >
> > rrdtool uses the time stamp you suply and then resamples the data
> > ... ignoring 'unknown' time ...
> >
> >> > from what you tell here I can not see what is going wrong ... best
> >> > is, if you write a little demo script to show your problem ...
> >>
> >> On the rrdtool fetch I provided,
> >>
> >> >> >> >1239617640: 9.9586069400e+02 1.7373722021e+01 5.6504290012e+01
> >> >> >> >1239617700: 9.9586000000e+02 1.7776053280e+01 5.7130494367e+01
> >> >> >> >1239617760: nan nan nan
> >> >> >> >1239617820: nan nan nan
> >> >> >> >1239617880: 9.8159131106e+02 1.9585499172e+01 4.9668510483e+01
> >> >> >> >1239617940: 9.9584083364e+02 2.0126658206e+01 5.0490830009e+01
> >> >> >> >1239618000: 9.9583079547e+02 2.0435340373e+01 5.1061476218e+01
> >>
> >> You can see a low-value of 981.59 for the first DS after the NaN time.
> >> I didn't entered any value lower than 995.8, so that cannot be a
> >> average!
> >
> > I know that you think you did not ... in order to verify this
> > problem, it helps when you provide an example constructed from
> > rrdtool create, rrdtool update, rrdtool fetch to demonstrate the
> > probem for others to reproduce ...
> >
> > there was an issue in connection with N: updates and long intervals
> > at some point, which may be hitting you if you are not using an
> > up-to-date version of rrdtool
> >
> > cheers
> > tobi
> >
> >>
> >> Nuno
> >>
> >> _______________________________________________
> >> rrd-users mailing list
> >> rrd-users at lists.oetiker.ch
> >> https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
> >>
> >>
> >
> > --
> > Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
> > http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900
>
>
>
>

-- 
Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland
http://it.oetiker.ch tobi at oetiker.ch ++41 62 775 9902 / sb: -9900