[rrd-users] Still having problems

[Simon Hobson]

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.