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
-- 
Dipl.-Inform. Till Dörges                      [email protected]
Senior Researcher                 Phone: +49 (0)700 / PRESECURE

PRESECURE Consulting GmbH, Münster         AG Münster, HRB 6581
Geschäftsführer/Managing Director   Dr. Klaus-Peter Kossakowski

                            CarmentiS - Early Warning Expertise
                                       http://www.carmentis.org

_______________________________________________
rrd-users mailing list
[email protected]
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users

Reply via email to