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: [email protected] [mailto:[email protected]] On Behalf Of Alex van den Bogaerdt Sent: Friday, 19 April 2013 8:24 AM To: [email protected] Subject: Re: [rrd-users] Dynamic Steps ----- Original Message ----- From: "Alan Finlay" <[email protected]> To: "'Alex van den Bogaerdt'" <[email protected]>; <[email protected]> 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 [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users _______________________________________________ rrd-users mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
