[rrd-users] Re: Compromised value after NaN

This is a discussion on [rrd-users] Re: Compromised value after NaN within the RRD Users forums, part of the Networking and Network Related category; On Fri, Dec 01, 2006 at 01:11:38PM +0100, Markus Wiget wrote: > > Use timestamps, not "N&...


Go Back   Usenet Forums > Networking and Network Related > RRD Users

FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 12-01-2006
Alex van den Bogaerdt
 
Posts: n/a
Default [rrd-users] Re: Compromised value after NaN

On Fri, Dec 01, 2006 at 01:11:38PM +0100, Markus Wiget wrote:

> > Use timestamps, not "N".

>
> What's wrong when using "N"? I just read in the man page that it is
> legal. Anyway, if I use explicit update time by replacing


So what? Did I say "It is illegal to use 'N'" ? No, I didn't.

Here's why I asked:

* Create rrdnan.rrd
* Feed data
(1 / 14:56:37) Updated N:100
(2 / 14:56:42) Updated N:100
(3 / 14:56:47) Updated N:100
(4 / 14:56:52) Updated N:100
(5 / 14:56:57) Updated N:100
(6 / 14:57:02) NOP
(7 / 14:57:07) Updated N:100
(8 / 14:57:12) Updated N:100
(9 / 14:57:17) Updated N:100
(10 / 14:57:22) Updated N:100
* Fetch data
testli

1164981385: nan
1164981390: nan
1164981395: nan
1164981400: 8.6187566667e+01
1164981405: 1.0000000000e+02
1164981410: 1.0000000000e+02
1164981415: 1.0000000000e+02
1164981420: nan
1164981425: nan
1164981430: 1.1806045000e+02
1164981435: 1.0000000000e+02
1164981440: 1.0000000000e+02
1164981445: nan
* Finished

As you can see, I get different values, because we used different
times. That happens because you use 'N' !

(side note: 1.1806045000e+02 seems a weird value. I am going to look into this)


> Anyway, if I use explicit update time by replacing
> s_date="N"
> with
> s_date="$(date '+%s')"
> then I get this output:
>
> [...]
> 1164967125: nan
> 1164967130: nan
> 1164967135: 1.0000000000e+02


Different result again. Part of the problem seems to be that
"N" and "$(date +%s)" aren't the same. The first one uses subsecond
precision, the second one does not. So "N" at 12:34:56 is not really
12:34:56, it is something like 12:34:56.121125479

Anyway, this modified script should produce equal results for all of
us, no matter when run:

sdate=1164981600

echo '* Create rrdnan.rrd'
rrdtool create rrdnan.rrd --step=5 \
--start 1164981600 \
DS:testli:GAUGE:7:0:100 \
RRA:AVERAGE:0.5:1:16

echo '* Feed data'
declare -i i
declare s_date
for i in $(seq 1 10); do
# no need to sleep 5
sdate=$((sdate+5))
if [ ${i} -ne 6 ]; then
rrdtool update rrdnan.rrd --template=testli ${sdate}:100
echo "(${i} Updated ${sdate}:100"
else
echo "(${i} NOP"
fi
done

echo '* Fetch data'
rrdtool fetch rrdnan.rrd AVERAGE --start=1164981600 --end=start+60

echo '* Finished'

It still produces two NaNs:
1164981625: 1.0000000000e+02
1164981630: nan
1164981635: nan
1164981640: 1.0000000000e+02


> #2 Why are there two NaN's?


> I thought it is because RRD always requires two values to build a row:
> the current and the previous value. This would mean for the first NaN,
> the current is missing and for the second NaN the previous is missing.
> But probably I'm totally wrong.


Two values are needed when RRDtool needs start and end of an interval,
and compute a rate from it. This is the case for a COUNTER. However,
for GAUGE, this is not needed.

This said: an unknown interval can be longer than just one interval.
In our current script, the amount of time for the known data at timestamp
1164981635 is unknown, therefore the interval 1164981630..1164981635 is
also unknown. Makes sense after all.

If an explicit NaN update at time 1164981630 would have occured, the
rate 1164981625..1164981630 would have been unknown but last update
time at 1164981630 would have been known. The update at 1164981635
would then have succeeded, producing rate 100 in stead of NaN.


You have "simplified the discussion" by altering heartbeat. What you
have really done is hide the truth: for timestamps _*exactly*_ equal
to a whole number times step, and with a heartbeat twice as large as
the step size (or more), there is _*no*_ gap:

1164981615: 1.0000000000e+02
1164981620: 1.0000000000e+02
1164981625: 1.0000000000e+02
1164981630: 1.0000000000e+02
1164981635: 1.0000000000e+02

All what's needed is to alter heartbeat 7 back into 10 (read: twice
the step) and stop using subsecond precision.

The update at 1164981635 is not more than ${heartbeat} seconds after
1164981625, thus it is valid, thus its rate is used in stead of NaN.

HTH
--
Alex van den Bogaerdt
http://www.vandenbogaerdt.nl/rrdtool/

--
Unsubscribe mailto:rrd-users-request@list.ee.ethz.ch?subject=unsubscribe
Help mailto:rrd-users-request@list.ee.ethz.ch?subject=help
Archive http://lists.ee.ethz.ch/rrd-users
WebAdmin http://lists.ee.ethz.ch/lsg2.cgi

Reply With Quote
Reply
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are Off
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On



All times are GMT +1. The time now is 11:56 AM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO 3.0.0