Re: [rrd-users] Not a simple unsigned integer
Hi Jonathan, Yesterday Silver, Jonathan wrote: We are getting this Not a simple unsigned integer error. I see from the forums that we have to provide integers for when metrocs are counters. Is there a real reason and requirement for this restriction? I'm curious. We have units = Kytes and we are passing 100.2 which is why we are getting the error. We also seem to be getting the error when sending a whole number of type Float. It really seems to me that rrdtool should not be so picky and should massage the data. We are actually using jmxtrans to collect the data and passing that through ganglia so it will be some work for us to resolve in the jvm, so any help and/or pointers are extremely appreciated. you only get this error for COUNTER and DERIVE type datasources. cheers tobi Thanks jonathan ___ rrd-users mailing list rrd-users@lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users -- Tobi Oetiker, OETIKER+PARTNER AG, Aarweg 15 CH-4600 Olten, Switzerland www.oetiker.ch t...@oetiker.ch +41 62 775 9902 ___ rrd-users mailing list rrd-users@lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
Re: [rrd-users] max / min values not precise? Bug?
spock collec...@sappers.de wrote: I have difficulties to interpret the graph created with the parameters below (I omitted some lines, but relevant data should be there). http://rrd-mailinglists.937164.n2.nabble.com/file/n7582374/tempmo1.png The graph shows - one line with high resolution data - one line with minimum values per day (step = 86400) - one line with maximum values per day (step = 86400) On the graph I do not understand, why the maximum value of the high resolution data does not correspond with the minimum / maximum values of the compressed data. Because the line is not showing all the data. On the first and second day e.g. the max values are higher than any data point of the actual high resolution data. # rrdtool create temp_pool.rrd --step 900 --start 20140101 00:00 \ graph_defs='-w 900 -h 525 -D -a PNG -T 15 --slope-mode \ First off, you haven't provided all the information - like what timescale the graph is plotted over (it looks like a bit over 2 weeks) or the actual data. At a step of 900s, that's 96 periods per day. Over 16 days, that's over 1500 periods. You are plotting a graph that's around a third of that in pixels, so around 3 points will be averaged per pixel. So you'd need to look carefully at the actual data to see what is missing from the graph you are plotting. What I've done for a few of my graphs is plot a shaded area between min and max. Do a CDEF x_spread=x_max,x_min,- (where x_min is x:MINIMUM and x_max is x:MAXIMUM) and plot an area with full transparency of x_min, then stack and area of (say) 50% transparency of x_spread on top of it. Then draw your line of x. I suspect that with your parameters you'll find that the shaded area touches the min and max lines. ___ rrd-users mailing list rrd-users@lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
Re: [rrd-users] How to calculate desired value?
spock collec...@sappers.de wrote: I tried: CDEF:heattime2=heat_flag,900,*,60,/ \ VDEF:totalheattime=heattime2,AVERAGE' GPRINT:totalheattime:Total\: %2.2lf h \n' but I get wrong results. I probably have to do the calculation completly different. Can anyone help me out here? I should get perfectly aligned values as a result: 0.25 h; 0.50h; etc. How can I achieve this? Give us a clue to go on, what values do you get ? Is it that you expected (say) 15 but got 14.99, or you got something completely different ? Your approach is right, I suspect rounding errors come into it. ___ rrd-users mailing list rrd-users@lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
Re: [rrd-users] How to calculate desired value?
Hi Simon, thanks for helping me out. I will include a more detailed example here: http://rrd-mailinglists.937164.n2.nabble.com/file/n7582382/tempday1.png The graph shows 24h; database has step 900 Lets take the grey area: we have 1 values from 09:30 to 19:45 = 10.25h. relevant graph parameters: DEF:heat_flag=temp_pool.rrd:heat_flag:AVERAGE \ DEF:pump_flag=temp_pool.rrd:pump_flag:AVERAGE \ CDEF:pumptime=pump_flag,1,EQ,INF,UNKN,IF \ CDEF:heattime=heat_flag,1,EQ,INF,UNKN,IF \ CDEF:heattime2=heat_flag,900,*,60,/ \ CDEF:pumptime2=pump_flag,900,*,60,/ \ VDEF:totalpumptime=pumptime2,AVERAGE \ VDEF:totalheattime=heattime2,AVERAGE' AREA:pumptime#10101010 \ AREA:heattime#FF15 \ LINE2:pump_flag#00 \ GPRINT:totalpumptime:Filterzeit\: %2.2lf h\ GPRINT:totalheattime:Heizzeit\: %2.2lf h \n' As you can see, the calculation for totalpumptime is 6.49h, although it should be 10.25h. The LINE2: pump_flag shows clearly, that the data is there, all 1 values - rest of the day 0 values. Thanks again, spock -- View this message in context: http://rrd-mailinglists.937164.n2.nabble.com/How-to-calculate-desired-value-tp7582375p7582382.html Sent from the RRDtool Users Mailinglist mailing list archive at Nabble.com. ___ rrd-users mailing list rrd-users@lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
Re: [rrd-users] max / min values not precise? Bug?
Hi Simon, Because the line is not showing all the data. I think the lines shows all the data. The timescale is 1 month (July 2014 = 31 days = 2976 data points). I tried to increase the x- resolution to 3000 pixel, but that did not change the graph. I was hoping, that - according to your statement - rrdtool does not have to average a few pixels to one data point, if the resolution is high enough. The red area in my example graph is exactly what you are asking for - but the blue line with the detailed data (roof) does not touch the upper limits of the red area (roof24harea). CDEF:roof24harea=roof24hmax,roof24hmin,- \ LINE2:roof#FF:Dach norm \ LINE2:roof24hmin#FF:Dachmin \ AREA:roof24harea#FF20::STACK \ LINE2:roof24hmax#00FF00:Dachmax' I think, that the DEF:roof24hmax=temp_pool.rrd:roof:MAX:step=86400 \ get a max value of about 59 ยด, whereas the LINE2:roof#FF:Dach norm \ does not show any data above 51 for the same day (Mi). The lower limits (MIN) seem to be ok though. Regards, Spock -- View this message in context: http://rrd-mailinglists.937164.n2.nabble.com/max-min-values-not-precise-Bug-tp7582374p7582383.html Sent from the RRDtool Users Mailinglist mailing list archive at Nabble.com. ___ rrd-users mailing list rrd-users@lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
Re: [rrd-users] How to calculate desired value?
- Original Message -
From: spock collec...@sappers.de
To: rrd-users@lists.oetiker.ch
Sent: Saturday, August 23, 2014 9:57 PM
Subject: Re: [rrd-users] How to calculate desired value?
Hi Simon, thanks for helping me out.
I will include a more detailed example here:
http://rrd-mailinglists.937164.n2.nabble.com/file/n7582382/tempday1.png
The graph shows 24h; database has step 900
Lets take the grey area:
we have 1 values from 09:30 to 19:45 = 10.25h.
I think it is 09:15, and 10.5 hours.
Relevant parameters include start and end time, number of pixels.
You should have --end {some timestamp equal to midnight} --start
end-24h --width {any number being a whole multiple of 96}
If not, something has to give and question #1 (see below) is answered.
You have a rate of 1 from 09:15 to 19:45. 10.5 hours
You have a rate of 0 from 00:00 to 09:15 and from 19:45 to 24:00. 9.25
hours and 4.25 hours, total 13.5 hours.
You compute the average rate, which is 10.5/24=0.4375.
You multiply that by 900, divide by 60, and the answer should be 6.5625 so
the two questions are:
1: why do you get a different outcome
2: why do you think you should multiply by 15 ( *900/60 is the same as *15)
to get hours?
The answer to question #1 could be as Simon suggested: rounding errors. I
expect the amount of time could be not exactly 24 hours.
The solution to question #2 is to think it over again. Assuming your start
and end times are exactly midnight, you are averaging over a 24 hour period,
you have an average pump on ratio which you should multiply by 24 to get
the amount of hours. The answer you should get would be 10.5 (or 10.25 if I
see things wrong) except for that (relatively small) error from question #1.
Further testing:
Fake some data, have the (fake) pump on during exactly 1 hour 23:00 the day
before until midnight, and no other times. Then print the average pump time.
It should be zero. In a different testing round, do the same from midnight
at the end of that day until 01:00. Again the average pump time should be
zero. If it is not in either test, then you know there is a problem with
the start time or the end time.
In a third test, have the pump on from 12:00 to 15:00. The average rate
should be exactly 0.125
Just print the average of pump_flag to debug, no CDEFs involved.
Look at the output of rrdtool dump and verify that it matches what you
expect.
Oh and by the way: i got confused because you started talking about
heat_flag and then switched to pump_flag. I know how it is when debugging,
it is easy to confuse yourself in similar ways. Whenever a value is not what
you expect, take a step back and look at the problem again.
HTH
Alex
___
rrd-users mailing list
rrd-users@lists.oetiker.ch
https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
