<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Calibri","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-AU link=blue vlink=purple><div class=WordSection1><p class=MsoNormal>Hi RRD users,<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thanks Alex for your response below in a different thread (Re: [rrd-users] Dynamic Steps). I will start new thread to avoid any further interference with that thread.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>You hit the nail on the head that I needed to understand that rrdtool stores rates as a “per second rate”. That was the key concept I overlooked in my understanding. I knew rrdtool converted to a rate, but since I was interested in counts per minute, I failed to notice it was counts per second I should be storing in rrdtool.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>My current approach to storing the counts per minute is using a GAUGE and storing the CPM value in rrdtool as if it were counts per second. Hence I am storing the value 60 time larger than it should be (or equivalently the units are CPS/60). That doesn’t cause any problem as long as I am aware of what I am storing (which I wasn’t).<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>When I converted to using an ABSOLUTE data store I needed to understand that I wanted counts per minute in the datastore, but was getting counts per second.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thanks again Alex for sparing the time to explain that.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Here is Alex’s post for reference:<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoPlainText style='margin-left:36.0pt'>> Clearly you understand something I don't. The value 0.366 is 22/60 I <o:p></o:p></p><p class=MsoPlainText style='margin-left:36.0pt'>> take it? But why should counts per second be stored? The rrd db defs <o:p></o:p></p><p class=MsoPlainText style='margin-left:36.0pt'>> are for a step size of 60 seconds, so I am expecting it to store <o:p></o:p></p><p class=MsoPlainText style='margin-left:36.0pt'>> counts per minute.<o:p></o:p></p><p class=MsoPlainText style='margin-left:36.0pt'><o:p> </o:p></p><p class=MsoPlainText style='margin-left:36.0pt'>Why? Because that is how it works. Always.<o:p></o:p></p><p class=MsoPlainText style='margin-left:36.0pt'><o:p> </o:p></p><p class=MsoPlainText style='margin-left:36.0pt'>Three clearly different steps to process your input: <o:p></o:p></p><p class=MsoPlainText style='margin-left:36.0pt'><a href="http://rrdtool.vandenbogaerdt.nl/process.php">http://rrdtool.vandenbogaerdt.nl/process.php</a><o:p></o:p></p><p class=MsoPlainText style='margin-left:36.0pt'><o:p> </o:p></p><p class=MsoPlainText style='margin-left:36.0pt'>Maybe it would have been better to call these steps "phases" so to not confuse step and step, but I'm not going to change it anymore now.<o:p></o:p></p><p class=MsoPlainText style='margin-left:36.0pt'><o:p> </o:p></p><p class=MsoPlainText style='margin-left:36.0pt'>First phase: compute a rate from the input, using a set of rules such as "GAUGE", "COUNTER" and so on. The value of "step" is not used here.<o:p></o:p></p><p class=MsoPlainText style='margin-left:36.0pt'><o:p> </o:p></p><p class=MsoPlainText style='margin-left:36.0pt'>Result: a rate. {something} per second. Yes, even when using RRDtool to store something like temperature, internally it is still handled as if it was a rate. We get away with this because we lie about the input: using GAUGE we are telling RRDtool the input is already {something per second} so don't touch. As a result, this "rate" goes to the next phase.<o:p></o:p></p><p class=MsoPlainText style='margin-left:36.0pt'><o:p> </o:p></p><p class=MsoPlainText style='margin-left:36.0pt'>Sorry for sidestepping. I just want to show: no matter what parameters you use, it is ALWAYS going to be a rate of {something} per second.<o:p></o:p></p><p class=MsoPlainText style='margin-left:36.0pt'><o:p> </o:p></p><p class=MsoPlainText style='margin-left:36.0pt'>We have a rate now, valid between the previous update and the current update. RRDtool does not work (by design) with arbitrary time intervals so this rate needs to be normalized into standard buckets of {step} seconds. <o:p></o:p></p><p class=MsoPlainText style='margin-left:36.0pt'>And this is where, and for what purpose, {step} is used.<o:p></o:p></p><p class=MsoPlainText style='margin-left:36.0pt'><o:p> </o:p></p><p class=MsoPlainText style='margin-left:36.0pt'>If you need higher precision, sample your input a lot (I mean: outside RRDtool), update a lot, and have a small {step} value (e.g. one second). See the web page I directed you to, the paragraph starting with "If you think it isn't ....", the part about the red rate could be twice as high as sampled. <o:p></o:p></p><p class=MsoPlainText style='margin-left:36.0pt'>If it is important to know the "real rate" (really only a better approximation), for instance in the case of a MAX consolidation function, then step should be really low *and* the input needs to be sampled often.<o:p></o:p></p><p class=MsoPlainText style='margin-left:36.0pt'><o:p> </o:p></p><p class=MsoPlainText style='margin-left:36.0pt'>Another sidestep: when updating multiple times per second, it could be useful to have {step} be smaller than one second. I don't know, and can currently not find out for myself, if this is possible. Please fill me in.<o:p></o:p></p><p class=MsoPlainText style='margin-left:36.0pt'><o:p> </o:p></p><p class=MsoPlainText style='margin-left:36.0pt'>The third and final phase is to build CDPs from PDPs, and store these CDPs into an RRA. Even if you use 3600 PDPs of one second each, the resulting CDP will still have a rate in {something} per second. This rate is just valid during a whole hour.<o:p></o:p></p><p class=MsoPlainText style='margin-left:36.0pt'><o:p> </o:p></p><p class=MsoPlainText style='margin-left:36.0pt'>This said, if you want to see "per minute" (or per hour, per 86400 seconds for a day, per 604800 seconds for a week) then just multiply your input, or the resulting rates, by the appropriate amount of seconds per unit you choose. After all, 0.3666666666666.... {something}s per second multiplied by<o:p></o:p></p><p class=MsoPlainText style='margin-left:36.0pt'>60 seconds, results in 22 {something}s.<o:p></o:p></p><p class=MsoPlainText style='margin-left:36.0pt'><o:p> </o:p></p><p class=MsoPlainText style='margin-left:36.0pt'>Although this is not a rule of some sorts, I prefer to keep the input 'as <o:p></o:p></p><p class=MsoPlainText style='margin-left:36.0pt'>is', and do such multiplications in a CDEF: CDEF:perminute=persecond,60,*<o:p></o:p></p><p class=MsoPlainText style='margin-left:36.0pt'><o:p> </o:p></p><p class=MsoPlainText style='margin-left:36.0pt'>But in the case of Wh, I recommend to multiply 'ticks' by 3600 at input time, because each tick is worth 3600 Joules, and this results in a clean database storing Joules per second aka Watt. Although this could also have been done in a CDEF, it just does not "feel right".<o:p></o:p></p><p class=MsoPlainText style='margin-left:36.0pt'><o:p> </o:p></p><p class=MsoPlainText style='margin-left:36.0pt'>To prevent another problem: no, after multiplying by 60 (either at graph time (CDEF) or at input time), the X-axis does not magically change. If the amount of PDPs per CDP is low enough (e.g. 1), and the step (duration of one<o:p></o:p></p><p class=MsoPlainText style='margin-left:36.0pt'>PDP) is low enough (e.g. 10 seconds), and the amount of time shown on the graph is low enough (e.g. 12 minutes), and the graph width is large enough (e.g. 360 pixels wide), you can still see "something per minute" change a couple of times during a minute. Using the example numbers I just gave, the resulting graph will show 72 CDPs of 10 seconds each, using 5 pixels per CDP. This results in a somewhat staircase looking graph.<o:p></o:p></p><p class=MsoPlainText style='margin-left:36.0pt'><o:p> </o:p></p><p class=MsoPlainText style='margin-left:36.0pt'>Similarly you can tweak your settings so that each of the stairs shows no less than 60 seconds, which would probably be a good idea if you use a "per minute" view. Just make sure each CDP contains n*60 seconds worth of data. <o:p></o:p></p><p class=MsoPlainText style='margin-left:36.0pt'>With {step} being equal to 1, this means you need 60 PDPs per CDP for a minute, or 3600 PDPs per CDP for an hour, and so on.<o:p></o:p></p><p class=MsoNormal style='margin-left:36.0pt'><o:p> </o:p></p><p class=MsoNormal>Alan F.<o:p></o:p></p></div></body></html>