[rrd-users] Still having problems

[Russell Handorf]

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 at lists.oetiker.ch
> https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
>