[rrd-users] Dynamic Steps

[Alan Finlay]

Hi Alex,

The rounding errors are due to my not using the timestamp to update, I was
using N, with the values in the trace coming from Unix in a debug statement.

Clearly you understand something I don't.  The value 0.366 is 22/60 I take
it?  But why should counts per second be stored?  The rrd db defs are for a
step size of 60 seconds, so I am expecting it to store counts per minute.

-----Original Message-----
From: rrd-users-bounces+alan.websites2=chankly.com at lists.oetiker.ch
[mailto:rrd-users-bounces+alan.websites2=chankly.com at lists.oetiker.ch] On
Behalf Of Alex van den Bogaerdt
Sent: Friday, 19 April 2013 8:24 AM
To: rrd-users at lists.oetiker.ch
Subject: Re: [rrd-users] Dynamic Steps


----- Original Message -----
From: "Alan Finlay" <alan.websites2 at chankly.com>
To: "'Alex van den Bogaerdt'" <alex at vandenbogaerdt.nl>;
<rrd-users at lists.oetiker.ch>
Sent: Thursday, April 18, 2013 1:41 PM
Subject: RE: [rrd-users] Dynamic Steps


> Hi Alex,
>
> Isn't this the same as the case I documented recently for my Geiger 
> counter where I have a step size of 1 minute and update an ABSOLUTE 
> counter every
> 5
> minutes.  See below I am updating every 5 seconds with integral values 
> "returned count=x".  In the minute from 1365867005 to 1365867060, I 
> did update 0+0+3+2+1+1+2+1+5+2+2+3=22 with result 0.36438774029 which 
> I don't understand at all.

Don't forget the interval between 1365867000 and 1365867005 which is also
part of this minute. It's the minute from 1365867000 to 1365867060.  22 
ticks in 60 seconds should result in 0.3666...   0.36438774029  is not 
correct but it is close. I suspect there are rounding errors involved.

Tobi, could you shed some light on this?


_______________________________________________
rrd-users mailing list
rrd-users at lists.oetiker.ch
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users