Re: [rrd-users] Still having problems

Thanks! I knew it was something I was doing, I just didnt understand
what. It's now working great.

r

Simon Hobson wrote:
> Russell Handorf wrote:
>
>
>> I have the DB setup like this
>>
>> $rrdtool create $rrd --start $timep --step 86400
>> DS:sql:ABSOLUTE:86400:0:10000000 RRA:MAX:0.5:1:6000
>>
>
>
>
>
>
>> $rrdtool update $rrd $time:$SQLJoinr
>>
>> $rrdtool = path to rrdtool
>> $rrd = the path and name of the rrd file
>> $time = the time in seconds of the line item being analyzed
>> $SQLJoinr = a low integer value, typically thus far less than 20 but can
>> be as high as the mid thousand
>>
>
>
>
>
>> I have no errors when I run through the program, and I have it
>> outputting the values listed above. This is where the frustrating part
>> comes. When I graph the values, they're not the whole integer's listed
>> as the value of $SQLJoinr. In fact, the numbers stored make no sense
>> whatsoever. I've run 'rrdtool dump' on the file to find the following:
>>
>> <rrd>
>> <version> 0003 </version>
>> <step> 86400 </step> <!-- Seconds -->
>> <lastupdate> 1176004800 </lastupdate> <!-- 2007-04-08 00:00:00
>> EDT -->
>>
>> <ds>
>> <name> sql </name>
>> <type> ABSOLUTE </type>
>> <minimal_heartbeat> 86400 </minimal_heartbeat>
>> <min> 0.0000000000e+00 </min>
>> <max> 1.0000000000e+07 </max>
>>
>> <!-- PDP Status -->
>> <last_ds> UNKN </last_ds>
>> <value> 4.1666666667e+00 </value>
>> <unknown_sec> 0 </unknown_sec>
>> </ds>
>> <rra>
>> <cf> MAX </cf>
>> <pdp_per_row> 1 </pdp_per_row> <!-- 86400 seconds -->
>>
>> <params>
>> <xff> 5.0000000000e-01 </xff>
>> </params>
>> <cdp_prep>
>> <ds>
>> <primary_value> 2.7584876543e-04 </primary_value>
>> <secondary_value> 0.0000000000e+00
>> </secondary_value>
>> <value> NaN </value>
>> <unknown_datapoints> 0 </unknown_datapoints>
>> </ds>
>> </cdp_prep>
>> <database>
>> <!-- 1990-11-03 19:00:00 EST / 657676800 -->
>> <row><v> NaN </v></row>
>> <!-- 1990-11-04 19:00:00 EST / 657763200 -->
>> <row><v> NaN </v></row>
>> <!-- 1990-11-05 19:00:00 EST / 657849600 -->
>> <row><v> NaN </v></row>
>> <!-- 1990-11-06 19:00:00 EST / 657936000 -->
>> <row><v> NaN </v></row>
>> ......<snip a whole bunch of dates, as to why it is going this far in
>> the past I have NO clue>.....
>>
>
> Because you told it to ? You told the program to create you a
> database storing 6000 samples at intervals of 86400 seconds, or 6000
> days. 6000 days is something in the region of 18 years so 1990 seems
> about right.
>
> It's a fundamental feature of an RRD which IS documented that it
> stores exactly the number of consolidated samples you tell it to and
> fills in values on a round robin basis. Ie your database size is
> fixed at the moment of creation, by inference filled with "nothing",
> and values are entered as time progresses with the oldest samples
> overwritten when the round robin pointer wraps around.
>
>
>
>> <!-- 2007-02-22 19:00:00 EST / 1172188800 -->
>> <row><v> NaN </v></row>
>> <!-- 2007-02-23 19:00:00 EST / 1172275200 -->
>> <row><v> 8.1018518519e-05 </v></row>
>> <!-- 2007-02-24 19:00:00 EST / 1172361600 -->
>> <row><v> 2.9176311728e-04 </v></row>
>> <!-- 2007-02-25 19:00:00 EST / 1172448000 -->
>> <row><v> 3.5638503086e-04 </v></row>
>> <!-- 2007-02-26 19:00:00 EST / 1172534400 -->
>> <row><v> 3.4047067901e-04 </v></row>
>> <!-- 2007-02-27 19:00:00 EST / 1172620800 -->
>>
> <snip>
>
>
>> Can someone please explain to me why this isnt working at all? Why does
>> it start all the way into the past back into the early 90's?
>>
>
> See above, because you told it to.
>
>
>> Why does it store the incorrect values?
>>
>
> Well to start with, you haven't said what the correct values are,
> beyond an indication of the range. But picking the first value of
> 8.1018518519e-05, multiply this by 86400 and you get 7.000128 - near
> enough 7, is that what you expected ?
>
> Let me repeat this, it seems to be one of the most misunderstood bits
> of the program. It only ever stores rates. Whatever you feed it, and
> whatever those numbers might relate to, internally they are all rates.
>
> So you feed in the number 7 after a one day interval. The program
> computes the rate as 7 / 86400 <somethings>/second and stores that -
> assuming you update on a step boundary.
>
> If your updates are not exactly on the step boundaries then the
> program will normalise what you feed it to fit. For example, if you
> do updates at half-time (ie 12 noon), then each stored sample will be
> 50% from one update, and 50% from the next. If you update at 6am,
> then stored samples would be 75% from one update, 25% from the next.
>
> In your case I think it's simply a matter of scaling. You can either
> multiply what you feed in by 86400, or you can multiply what comes
> out by 86400 when you come to graph it.
>
>
> _______________________________________________
> rrd-users mailing list
> rrd-users@lists.oetiker.ch
> https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
>

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