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