[rrd-users] RRDs with unpredictable update time

[Tobias Oetiker]

Hi Till,

sorry I confused you with another user ... in your case, the
'double' updates should look like this:

rrdtool create test.rrd --start=1237923600 DS:events:GAUGE:600:0:U RRA:AVERAGE:0.5:1:2016
rrdtool update test.rrd '1237923600:0'	# step 1
rrdtool update test.rrd '1237923900:123'	# step 2
rrdtool update test.rrd '1237924900:0'	# step 3
rrdtool update test.rrd '1237924200:456'	# step 4
rrdtool update test.rrd '1237924200:0'	# step 5
rrdtool update test.rrd '1237924500:789'	# step 6
rrdtool update test.rrd '1237931400:0'	# step 7
rrdtool update test.rrd '1237931700:1111'	# step 8
rrdtool update test.rrd '1237938600:0'	# step 9
rrdtool update test.rrd '1237938900:2222'	# step 10

as you can see, up until step number 5 the 0 updates will be
refused since they are duplicates, but for steps 8 and 10 the
updates 7 and 9 will make sure that rrdtool does NOT assume the
data to have gone unknown for the whole interval, it will make sure
that the last 300 seconds will be taken into account

cheers
tobi





Yesterday Till Dörges wrote:

> Hi Tobias,
>
> thanks for your answer.
>
> On 28.03.2009 17:37, Tobias Oetiker wrote:
>
> > this will not create corect results, since in GAUGE, rrdtool
> > assumes that for every update the value of the GAUGE datasource has
> > been at the new value since the last update.
> >
> > so if your updates are at irregular intervals, the updates after
> > long intervals wil have undue weight
> >
> > also how would you handle the case when 2 updates arrive in one
> > second ?
>
> The updates come irregularly but they are at least 5 minutes (300 sec) apart. And
> they are always on a 5 minute boundary.
>
> I *think* RRD does the following when I do my "double update":
>
> Given these datapoints
>
>  time         events
> ---------------------
>  t_0             123
>  t_0 +    5m     456
>  t_0 +   10m     789
>  t_0 + 2h10m    1111
>  t_0 + 4h10m    2222
>
> and this RRD
>
> --- snip ---
> rrdtool create test.rrd --start=1237923600 DS:events:GAUGE:600:0:U RRA:AVERAGE:0.5:1:2016
> rrdtool update test.rrd '1237923899:123'	# step 1
> rrdtool update test.rrd '1237923900:123'	# step 2
> rrdtool update test.rrd '1237924199:456'	# step 3
> rrdtool update test.rrd '1237924200:456'	# step 4
> rrdtool update test.rrd '1237924499:789'	# step 5
> rrdtool update test.rrd '1237924500:789'	# step 6
> rrdtool update test.rrd '1237931699:1111'	# step 7
> rrdtool update test.rrd '1237931700:1111'	# step 8
> rrdtool update test.rrd '1237938899:2222'	# step 9
> rrdtool update test.rrd '1237938900:2222'	# step 10
> --- snap ---
>
>
> After step 1 the datasource events is set to 123. After step 2 the ds is set to 123
> and RRD tries to build the first PDP for 1237923900. Averaging 123 (1237923899) and
> 123 (1237923900) gives 123.
> This repeats analogously for steps 3 to 6.
> After step 7 RRD sets the ds to 1111 but doesn't have enough data to compute PDPs for
> 1237924800 to 1237931400 and sets them to NaN. After step 8 the ds is set to 1111.
> RRD then averages 1111 (1237931699) and 1111 (1237931700) to set the PDP for
> 1237931700 to 1111.
>
>
> I'm not sure I understood the inner workings of RRD correctly. But if I did, the
> behavior of RRD would perfectly fit my needs.
>
>
> Regards -- Till
>

-- 
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