> I have pretty much spent whole day today trying to figure out how mrtg > calculates the "current" value for in and out bandwidth usage. > > I have even tried to decipher the perl code, without much luck. > > If anyone has a quick explanation, or can push me in the right direction, > I would be most grateful.
http://www.steveshipway.org/book/ The book has some details in it on how things work. Plug, plug. ;-) Assuming firstly that you're talking about a normal Counter Target (such as a network traffic rate), basically it is ((most recently polled value)-(previously polled value))/(time interval) However, there are a couple more issues to do with data normalisation that affect this on a small scale. Firstly, imagine time carved up into 5min chunks from the hour boundary -- 12:00:00-12:04:59, 12:05:00-12:09:59 and so on. Each chunk has ONE polling only, preferably on the first second. If there has not been a poll yet for the chunk we're in, then the 'current' value is UNKNOWN, although some frontends compensate for this by hopping back in time one chunk. If a value comes in at 12:01, then this is 'normalised' back to what it should have been at 12:00 by interpolating a straight line. So, if the value was 10 in the previous chunk (11:55), and we polled 16 at 12:01, then by straight line interpolation we get 15, which is what we store for 12:00. Next, if this is a 'counter', we calculate the rate as: (15-10)/5 = 1 per minute. Gauges are taken as-is and other data types like 'derive' are processed appropriately. When you're dealing with the big numbers in network counters, this behaviour is almost invisible, and makes things much easier. When the numbers are small counters (eg, pages printed on network printer) you can get unexplained fractional values. This normalisation is done so that the final database has samples with precisely regular timing - 12:00, 12:05, etc - which makes the graphing and stats easier. However it does make MRTG/RRDtool inappropriate for things other than regular data gathering. There is currently no option to MRTG (or RRDTool) to specify that a polled value should not be normalised, other than to explicitly store it against the base time of the chunk (which you cannot do with MRTG unless you time your polls carefully). Hope this helps... Steve _______________________________________________ mrtg mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/mrtg
