Re: [unsure] Adding updates but fetch shows NaNs

--===============0369316722618505854==
Content-Type: multipart/alternative; boundary="001a113d1044d4acbd056375cc38"

--001a113d1044d4acbd056375cc38
Content-Type: text/plain; charset="UTF-8"

Thanks, Alex! The last but about the double update did it for me.
I split my Python script into two objects which each did their own
rrdupdate and set half the values to U.
By combining the data into a single update, my values are now working just
fine.
I thought that the U would be the same as no-update but apparently not.

On Mon, Jan 22, 2018 at 11:18 PM, Alex van den Bogaerdt <
[email protected]> wrote:

> > I was hoping someone could help me understand how values are computed in
> > RRD.
> > I got a temp database (create below). I got a loop that adds an update
> > ever
> > ~2 minutes.
>
> 120 seconds.
>
> And your interval (database step) is 200 seconds.
>
> > rrdtool info says the DS got known values for the last two
> > columns (ext_temperature, ext_humidity).
>
> and also reports part of the interval is unknown.
>
> Guessing here, I did not do all the exercises: my guess is that you always
> have part of an interval set to unknown data.
>
> Suggestion to debug, and maybe also to make permanent changes to your
> database setup:
>
> 1: set your database to step==1
> 2: the RRAs you already have, collect data 200x the current step size
> (e.g. you now have RRA:AVERAGE:0.5:1:2016 this becomes
> RRA:AVERAGE:0.5:200:2016 )
> 3: an extra RRA expects data every 1 step. It won't get it that often, but
> that does not matter. Just make sure heartbeat is set high enough.
> 4: also keep MIN and MAX if so desired
>
> This new, extra RRA aids in debugging. Just make it long enough to look
> back an hour or so (3600 seconds). Longer if you wish to keep and use the
> data. Disk space is cheap.
>
> Your previous setup: one complete interval was 200 seconds and you needed
> at least 2 updates for it to fill. The new proposed setup completes more
> than one interval of 1 second each time you update.
>
> If you see weird rates in the first interval of such ranges (rates being
> pulled to zero), then your version of RRDtool suffers from the
> sub-second-precision bug. Ignore, or make sure you update with integer
> timestamps instead of "N" for now.
>
>
> Last but not least:  if you receive your data as one batch of numbers,
> then never mind but if you receive your numbers separate from each other,
> then do not combine them in one RRD database.
>
> E.g. update x:1:2:3:4:5:6:U:U followed by update x+1:U:U:U:U:U:U:1:2
> messes things up. It will NOT result in only updating the first 6 DSes and
> then only the last 2.
>
> HTH
> Alex
>
>
>

--001a113d1044d4acbd056375cc38
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thanks, Alex! The last but about the double update did it =
for me.<div>I split my Python script into two objects which each did their =
own rrdupdate and set half the values to U.</div><div>By combining the data=
 into a single update, my values are now working just fine.=C2=A0</div><div=
>I thought that the U would be the same as no-update but apparently not.</d=
iv></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, =
Jan 22, 2018 at 11:18 PM, Alex van den Bogaerdt <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:[email protected]" target=3D"_blank">alex@vandenbogaerdt.=
nl</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D""=
>&gt; I was hoping someone could help me understand how values are computed=
 in<br>
&gt; RRD.<br>
&gt; I got a temp database (create below). I got a loop that adds an update=
<br>
&gt; ever<br>
&gt; ~2 minutes.<br>
<br>
</span>120 seconds.<br>
<br>
And your interval (database step) is 200 seconds.<br>
<span class=3D""><br>
&gt; rrdtool info says the DS got known values for the last two<br>
&gt; columns (ext_temperature, ext_humidity).<br>
<br>
</span>and also reports part of the interval is unknown.<br>
<br>
Guessing here, I did not do all the exercises: my guess is that you always<=
br>
have part of an interval set to unknown data.<br>
<br>
Suggestion to debug, and maybe also to make permanent changes to your<br>
database setup:<br>
<br>
1: set your database to step=3D=3D1<br>
2: the RRAs you already have, collect data 200x the current step size<br>
(e.g. you now have RRA:AVERAGE:0.5:1:2016 this becomes<br>
RRA:AVERAGE:0.5:200:2016 )<br>
3: an extra RRA expects data every 1 step. It won&#39;t get it that often, =
but<br>
that does not matter. Just make sure heartbeat is set high enough.<br>
4: also keep MIN and MAX if so desired<br>
<br>
This new, extra RRA aids in debugging. Just make it long enough to look<br>
back an hour or so (3600 seconds). Longer if you wish to keep and use the<b=
r>
data. Disk space is cheap.<br>
<br>
Your previous setup: one complete interval was 200 seconds and you needed<b=
r>
at least 2 updates for it to fill. The new proposed setup completes more<br=
>
than one interval of 1 second each time you update.<br>
<br>
If you see weird rates in the first interval of such ranges (rates being<br=
>
pulled to zero), then your version of RRDtool suffers from the<br>
sub-second-precision bug. Ignore, or make sure you update with integer<br>
timestamps instead of &quot;N&quot; for now.<br>
<br>
<br>
Last but not least:=C2=A0 if you receive your data as one batch of numbers,=
<br>
then never mind but if you receive your numbers separate from each other,<b=
r>
then do not combine them in one RRD database.<br>
<br>
E.g. update x:1:2:3:4:5:6:U:U followed by update x+1:U:U:U:U:U:U:1:2<br>
messes things up. It will NOT result in only updating the first 6 DSes and<=
br>
then only the last 2.<br>
<br>
HTH<br>
<span class=3D"HOEnZb"><font color=3D"#888888">Alex<br>
<br>
<br>
</font></span></blockquote></div><br></div>

--001a113d1044d4acbd056375cc38--


--===============0369316722618505854==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0369316722618505854==--