Code

Imported upstream version 1.3.8.
[pkg-rrdtool.git] / doc / rrdcreate.txt
index 197959d5335442217aa8d2cc56ec6582bbc41ff0..0a82202f8b90692bf854440a7060c4d20af65456 100644 (file)
@@ -14,189 +14,173 @@ D\bDE\bES\bSC\bCR\bRI\bIP\bPT\bTI\bIO\bON\bN
        (R\bRR\bRD\bD) files.  The file is created at its final, full size and filled
        with _\b*_\bU_\bN_\bK_\bN_\bO_\bW_\bN_\b* data.
 
-       _\bf_\bi_\bl_\be_\bn_\ba_\bm_\be
-               The name of the R\bRR\bRD\bD you want to create. R\bRR\bRD\bD files should end
-               with the extension _\b._\br_\br_\bd. However, R\bRR\bRD\bDt\bto\boo\bol\bl will accept any file-
-               name.
-
-       -\b--\b-s\bst\bta\bar\brt\bt|-\b-b\bb _\bs_\bt_\ba_\br_\bt _\bt_\bi_\bm_\be (default: now - 10s)
-               Specifies the time in seconds since 1970-01-01 UTC when the
-               first value should be added to the R\bRR\bRD\bD. R\bRR\bRD\bDt\bto\boo\bol\bl will not accept
-               any data timed before or at the time specified.
-
-               See also AT-STYLE TIME SPECIFICATION section in the _\br_\br_\bd_\bf_\be_\bt_\bc_\bh
-               documentation for other ways to specify time.
-
-       -\b--\b-s\bst\bte\bep\bp|-\b-s\bs _\bs_\bt_\be_\bp (default: 300 seconds)
-               Specifies the base interval in seconds with which data will be
-               fed into the R\bRR\bRD\bD.
-
-       D\bDS\bS:\b:_\bd_\bs_\b-_\bn_\ba_\bm_\be:\b:_\bD_\bS_\bT:\b:_\bd_\bs_\bt _\ba_\br_\bg_\bu_\bm_\be_\bn_\bt_\bs
-               A single R\bRR\bRD\bD can accept input from several data sources (D\bDS\bS),
-               for example incoming and outgoing traffic on a specific commu-
-               nication line. With the D\bDS\bS configuration option you must define
-               some basic properties of each data source you want to store in
-               the R\bRR\bRD\bD.
-
-               _\bd_\bs_\b-_\bn_\ba_\bm_\be is the name you will use to reference this particular
-               data source from an R\bRR\bRD\bD. A _\bd_\bs_\b-_\bn_\ba_\bm_\be must be 1 to 19 characters
-               long in the characters [a-zA-Z0-9_].
-
-               _\bD_\bS_\bT defines the Data Source Type. The remaining arguments of a
-               data source entry depend on the data source type. For GAUGE,
-               COUNTER, DERIVE, and ABSOLUTE the format for a data source
-               entry is:
-
-               D\bDS\bS:\b:_\bd_\bs_\b-_\bn_\ba_\bm_\be:\b:_\bG_\bA_\bU_\bG_\bE _\b| _\bC_\bO_\bU_\bN_\bT_\bE_\bR _\b| _\bD_\bE_\bR_\bI_\bV_\bE _\b| _\bA_\bB_\bS_\bO_\bL_\bU_\bT_\bE:\b:_\bh_\be_\ba_\br_\bt_\b-
-               _\bb_\be_\ba_\bt:\b:_\bm_\bi_\bn:\b:_\bm_\ba_\bx
-
-               For COMPUTE data sources, the format is:
-
-               D\bDS\bS:\b:_\bd_\bs_\b-_\bn_\ba_\bm_\be:\b:_\bC_\bO_\bM_\bP_\bU_\bT_\bE:\b:_\br_\bp_\bn_\b-_\be_\bx_\bp_\br_\be_\bs_\bs_\bi_\bo_\bn
-
-               In order to decide which data source type to use, review the
-               definitions that follow. Also consult the section on "HOW TO
-               MEASURE" for further insight.
-
-               G\bGA\bAU\bUG\bGE\bE
-                   is for things like temperatures or number of people in a
-                   room or the value of a RedHat share.
-
-               C\bCO\bOU\bUN\bNT\bTE\bER\bR
-                   is for continuous incrementing counters like the ifInOctets
-                   counter in a router. The C\bCO\bOU\bUN\bNT\bTE\bER\bR data source assumes that
-                   the counter never decreases, except when a counter over-
-                   flows.  The update function takes the overflow into
-                   account.  The counter is stored as a per-second rate. When
-                   the counter overflows, RRDtool checks if the overflow hap-
-                   pened at the 32bit or 64bit border and acts accordingly by
-                   adding an appropriate value to the result.
-
-               D\bDE\bER\bRI\bIV\bVE\bE
-                   will store the derivative of the line going from the last
-                   to the current value of the data source. This can be useful
-                   for gauges, for example, to measure the rate of people
-                   entering or leaving a room. Internally, derive works
-                   exactly like COUNTER but without overflow checks. So if
-                   your counter does not reset at 32 or 64 bit you might want
-                   to use DERIVE and combine it with a MIN value of 0.
-
-                   NOTE on COUNTER vs DERIVE
-                       by Don Baarda <don.baarda@baesystems.com>
-
-                       If you cannot tolerate ever mistaking the occasional
-                       counter reset for a legitimate counter wrap, and would
-                       prefer "Unknowns" for all legitimate counter wraps and
-                       resets, always use DERIVE with min=0. Otherwise, using
-                       COUNTER with a suitable max will return correct values
-                       for all legitimate counter wraps, mark some counter
-                       resets as "Unknown", but can mistake some counter
-                       resets for a legitimate counter wrap.
-
-                       For a 5 minute step and 32-bit counter, the probability
-                       of mistaking a counter reset for a legitimate wrap is
-                       arguably about 0.8% per 1Mbps of maximum bandwidth.
-                       Note that this equates to 80% for 100Mbps interfaces,
-                       so for high bandwidth interfaces and a 32bit counter,
-                       DERIVE with min=0 is probably preferable. If you are
-                       using a 64bit counter, just about any max setting will
-                       eliminate the possibility of mistaking a reset for a
-                       counter wrap.
-
-               A\bAB\bBS\bSO\bOL\bLU\bUT\bTE\bE
-                   is for counters which get reset upon reading. This is used
-                   for fast counters which tend to overflow. So instead of
-                   reading them normally you reset them after every read to
-                   make sure you have a maximum time available before the next
-                   overflow. Another usage is for things you count like number
-                   of messages since the last update.
-
-               C\bCO\bOM\bMP\bPU\bUT\bTE\bE
-                   is for storing the result of a formula applied to other
-                   data sources in the R\bRR\bRD\bD. This data source is not supplied a
-                   value on update, but rather its Primary Data Points (PDPs)
-                   are computed from the PDPs of the data sources according to
-                   the rpn-expression that defines the formula. Consolidation
-                   functions are then applied normally to the PDPs of the COM-
-                   PUTE data source (that is the rpn-expression is only
-                   applied to generate PDPs). In database software, such data
-                   sets are referred to as "virtual" or "computed" columns.
-
-               _\bh_\be_\ba_\br_\bt_\bb_\be_\ba_\bt defines the maximum number of seconds that may pass
-               between two updates of this data source before the value of the
-               data source is assumed to be _\b*_\bU_\bN_\bK_\bN_\bO_\bW_\bN_\b*.
-
-               _\bm_\bi_\bn and _\bm_\ba_\bx define the expected range values for data supplied
-               by a data source. If _\bm_\bi_\bn and/or _\bm_\ba_\bx any value outside the
-               defined range will be regarded as _\b*_\bU_\bN_\bK_\bN_\bO_\bW_\bN_\b*. If you do not know
-               or care about min and max, set them to U for unknown. Note that
-               min and max always refer to the processed values of the DS. For
-               a traffic-C\bCO\bOU\bUN\bNT\bTE\bER\bR type DS this would be the maximum and minimum
-               data-rate expected from the device.
-
-               _\bI_\bf _\bi_\bn_\bf_\bo_\br_\bm_\ba_\bt_\bi_\bo_\bn _\bo_\bn _\bm_\bi_\bn_\bi_\bm_\ba_\bl_\b/_\bm_\ba_\bx_\bi_\bm_\ba_\bl _\be_\bx_\bp_\be_\bc_\bt_\be_\bd _\bv_\ba_\bl_\bu_\be_\bs _\bi_\bs _\ba_\bv_\ba_\bi_\bl_\ba_\bb_\bl_\be_\b,
-               _\ba_\bl_\bw_\ba_\by_\bs _\bs_\be_\bt _\bt_\bh_\be _\bm_\bi_\bn _\ba_\bn_\bd_\b/_\bo_\br _\bm_\ba_\bx _\bp_\br_\bo_\bp_\be_\br_\bt_\bi_\be_\bs_\b. _\bT_\bh_\bi_\bs _\bw_\bi_\bl_\bl _\bh_\be_\bl_\bp _\bR_\bR_\bD_\b-
-               _\bt_\bo_\bo_\bl _\bi_\bn _\bd_\bo_\bi_\bn_\bg _\ba _\bs_\bi_\bm_\bp_\bl_\be _\bs_\ba_\bn_\bi_\bt_\by _\bc_\bh_\be_\bc_\bk _\bo_\bn _\bt_\bh_\be _\bd_\ba_\bt_\ba _\bs_\bu_\bp_\bp_\bl_\bi_\be_\bd _\bw_\bh_\be_\bn
-               _\br_\bu_\bn_\bn_\bi_\bn_\bg _\bu_\bp_\bd_\ba_\bt_\be_\b.
-
-               _\br_\bp_\bn_\b-_\be_\bx_\bp_\br_\be_\bs_\bs_\bi_\bo_\bn defines the formula used to compute the PDPs of
-               a COMPUTE data source from other data sources in the same
-               <RRD>. It is similar to defining a C\bCD\bDE\bEF\bF argument for the graph
-               command. Please refer to that manual page for a list and
-               description of RPN operations supported. For COMPUTE data
-               sources, the following RPN operations are not supported: COUNT,
-               PREV, TIME, and LTIME. In addition, in defining the RPN expres-
-               sion, the COMPUTE data source may only refer to the names of
-               data source listed previously in the create command. This is
-               similar to the restriction that C\bCD\bDE\bEF\bFs must refer only to D\bDE\bEF\bFs
-               and C\bCD\bDE\bEF\bFs previously defined in the same graph command.
-
-       R\bRR\bRA\bA:\b:_\bC_\bF:\b:_\bc_\bf _\ba_\br_\bg_\bu_\bm_\be_\bn_\bt_\bs
-               The purpose of an R\bRR\bRD\bD is to store data in the round robin
-               archives (R\bRR\bRA\bA). An archive consists of a number of data values
-               or statistics for each of the defined data-sources (D\bDS\bS) and is
-               defined with an R\bRR\bRA\bA line.
-
-               When data is entered into an R\bRR\bRD\bD, it is first fit into time
-               slots of the length defined with the -\b-s\bs option, thus becoming a
-               _\bp_\br_\bi_\bm_\ba_\br_\by _\bd_\ba_\bt_\ba _\bp_\bo_\bi_\bn_\bt.
-
-               The data is also processed with the consolidation function (_\bC_\bF)
-               of the archive. There are several consolidation functions that
-               consolidate primary data points via an aggregate function:
-               A\bAV\bVE\bER\bRA\bAG\bGE\bE, M\bMI\bIN\bN, M\bMA\bAX\bX, L\bLA\bAS\bST\bT.
-
-               AVERAGE
-                   the average of the data points is stored.
-
-               MIN the smallest of the data points is stored.
-
-               MAX the largest of the data points is stored.
-
-               LAST
-                   the last data points is used.
-
-               Note that data aggregation inevitably leads to loss of preci-
-               sion and information. The trick is to pick the aggregate func-
-               tion such that the _\bi_\bn_\bt_\be_\br_\be_\bs_\bt_\bi_\bn_\bg properties of your data is kept
-               across the aggregation process.
-
-               The format of R\bRR\bRA\bA line for these consolidation functions is:
-
-               R\bRR\bRA\bA:\b:_\bA_\bV_\bE_\bR_\bA_\bG_\bE _\b| _\bM_\bI_\bN _\b| _\bM_\bA_\bX _\b| _\bL_\bA_\bS_\bT:\b:_\bx_\bf_\bf:\b:_\bs_\bt_\be_\bp_\bs:\b:_\br_\bo_\bw_\bs
-
-               _\bx_\bf_\bf The xfiles factor defines what part of a consolidation
-               interval may be made up from _\b*_\bU_\bN_\bK_\bN_\bO_\bW_\bN_\b* data while the consoli-
-               dated value is still regarded as known. It is given as the
-               ratio of allowed _\b*_\bU_\bN_\bK_\bN_\bO_\bW_\bN_\b* PDPs to the number of PDPs in the
-               interval. Thus, it ranges from 0 to 1 (exclusive).
-
-               _\bs_\bt_\be_\bp_\bs defines how many of these _\bp_\br_\bi_\bm_\ba_\br_\by _\bd_\ba_\bt_\ba _\bp_\bo_\bi_\bn_\bt_\bs are used to
-               build a _\bc_\bo_\bn_\bs_\bo_\bl_\bi_\bd_\ba_\bt_\be_\bd _\bd_\ba_\bt_\ba _\bp_\bo_\bi_\bn_\bt which then goes into the
-               archive.
-
-               _\br_\bo_\bw_\bs defines how many generations of data values are kept in an
-               R\bRR\bRA\bA.
+   _\bf_\bi_\bl_\be_\bn_\ba_\bm_\be
+       The name of the R\bRR\bRD\bD you want to create. R\bRR\bRD\bD files should end with the
+       extension _\b._\br_\br_\bd. However, R\bRR\bRD\bDt\bto\boo\bol\bl will accept any filename.
+
+   -\b--\b-s\bst\bta\bar\brt\bt|\b|-\b-b\bb _\bs_\bt_\ba_\br_\bt _\bt_\bi_\bm_\be (\b(d\bde\bef\bfa\bau\bul\blt\bt:\b: n\bno\bow\bw -\b- 1\b10\b0s\bs)\b)
+       Specifies the time in seconds since 1970-01-01 UTC when the first value
+       should be added to the R\bRR\bRD\bD. R\bRR\bRD\bDt\bto\boo\bol\bl will not accept any data timed
+       before or at the time specified.
+
+       See also AT-STYLE TIME SPECIFICATION section in the _\br_\br_\bd_\bf_\be_\bt_\bc_\bh
+       documentation for other ways to specify time.
+
+   -\b--\b-s\bst\bte\bep\bp|\b|-\b-s\bs _\bs_\bt_\be_\bp (\b(d\bde\bef\bfa\bau\bul\blt\bt:\b: 3\b30\b00\b0 s\bse\bec\bco\bon\bnd\bds\bs)\b)
+       Specifies the base interval in seconds with which data will be fed into
+       the R\bRR\bRD\bD.
+
+   D\bDS\bS:\b:_\bd_\bs_\b-_\bn_\ba_\bm_\be:\b:_\bD_\bS_\bT:\b:_\bd_\bs_\bt _\ba_\br_\bg_\bu_\bm_\be_\bn_\bt_\bs
+       A single R\bRR\bRD\bD can accept input from several data sources (D\bDS\bS), for
+       example incoming and outgoing traffic on a specific communication line.
+       With the D\bDS\bS configuration option you must define some basic properties
+       of each data source you want to store in the R\bRR\bRD\bD.
+
+       _\bd_\bs_\b-_\bn_\ba_\bm_\be is the name you will use to reference this particular data
+       source from an R\bRR\bRD\bD. A _\bd_\bs_\b-_\bn_\ba_\bm_\be must be 1 to 19 characters long in the
+       characters [a-zA-Z0-9_].
+
+       _\bD_\bS_\bT defines the Data Source Type. The remaining arguments of a data
+       source entry depend on the data source type. For GAUGE, COUNTER,
+       DERIVE, and ABSOLUTE the format for a data source entry is:
+
+       D\bDS\bS:\b:_\bd_\bs_\b-_\bn_\ba_\bm_\be:\b:_\bG_\bA_\bU_\bG_\bE _\b| _\bC_\bO_\bU_\bN_\bT_\bE_\bR _\b| _\bD_\bE_\bR_\bI_\bV_\bE _\b| _\bA_\bB_\bS_\bO_\bL_\bU_\bT_\bE:\b:_\bh_\be_\ba_\br_\bt_\bb_\be_\ba_\bt:\b:_\bm_\bi_\bn:\b:_\bm_\ba_\bx
+
+       For COMPUTE data sources, the format is:
+
+       D\bDS\bS:\b:_\bd_\bs_\b-_\bn_\ba_\bm_\be:\b:_\bC_\bO_\bM_\bP_\bU_\bT_\bE:\b:_\br_\bp_\bn_\b-_\be_\bx_\bp_\br_\be_\bs_\bs_\bi_\bo_\bn
+
+       In order to decide which data source type to use, review the
+       definitions that follow. Also consult the section on "HOW TO MEASURE"
+       for further insight.
+
+       G\bGA\bAU\bUG\bGE\bE
+           is for things like temperatures or number of people in a room or
+           the value of a RedHat share.
+
+       C\bCO\bOU\bUN\bNT\bTE\bER\bR
+           is for continuous incrementing counters like the ifInOctets counter
+           in a router. The C\bCO\bOU\bUN\bNT\bTE\bER\bR data source assumes that the counter never
+           decreases, except when a counter overflows.  The update function
+           takes the overflow into account.  The counter is stored as a per-
+           second rate. When the counter overflows, RRDtool checks if the
+           overflow happened at the 32bit or 64bit border and acts accordingly
+           by adding an appropriate value to the result.
+
+       D\bDE\bER\bRI\bIV\bVE\bE
+           will store the derivative of the line going from the last to the
+           current value of the data source. This can be useful for gauges,
+           for example, to measure the rate of people entering or leaving a
+           room. Internally, derive works exactly like COUNTER but without
+           overflow checks. So if your counter does not reset at 32 or 64 bit
+           you might want to use DERIVE and combine it with a MIN value of 0.
+
+           N\bNO\bOT\bTE\bE o\bon\bn C\bCO\bOU\bUN\bNT\bTE\bER\bR v\bvs\bs D\bDE\bER\bRI\bIV\bVE\bE
+
+           by Don Baarda <don.baarda@baesystems.com>
+
+           If you cannot tolerate ever mistaking the occasional counter reset
+           for a legitimate counter wrap, and would prefer "Unknowns" for all
+           legitimate counter wraps and resets, always use DERIVE with min=0.
+           Otherwise, using COUNTER with a suitable max will return correct
+           values for all legitimate counter wraps, mark some counter resets
+           as "Unknown", but can mistake some counter resets for a legitimate
+           counter wrap.
+
+           For a 5 minute step and 32-bit counter, the probability of
+           mistaking a counter reset for a legitimate wrap is arguably about
+           0.8% per 1Mbps of maximum bandwidth. Note that this equates to 80%
+           for 100Mbps interfaces, so for high bandwidth interfaces and a
+           32bit counter, DERIVE with min=0 is probably preferable. If you are
+           using a 64bit counter, just about any max setting will eliminate
+           the possibility of mistaking a reset for a counter wrap.
+
+       A\bAB\bBS\bSO\bOL\bLU\bUT\bTE\bE
+           is for counters which get reset upon reading. This is used for fast
+           counters which tend to overflow. So instead of reading them
+           normally you reset them after every read to make sure you have a
+           maximum time available before the next overflow. Another usage is
+           for things you count like number of messages since the last update.
+
+       C\bCO\bOM\bMP\bPU\bUT\bTE\bE
+           is for storing the result of a formula applied to other data
+           sources in the R\bRR\bRD\bD. This data source is not supplied a value on
+           update, but rather its Primary Data Points (PDPs) are computed from
+           the PDPs of the data sources according to the rpn-expression that
+           defines the formula. Consolidation functions are then applied
+           normally to the PDPs of the COMPUTE data source (that is the rpn-
+           expression is only applied to generate PDPs). In database software,
+           such data sets are referred to as "virtual" or "computed" columns.
+
+       _\bh_\be_\ba_\br_\bt_\bb_\be_\ba_\bt defines the maximum number of seconds that may pass between
+       two updates of this data source before the value of the data source is
+       assumed to be _\b*_\bU_\bN_\bK_\bN_\bO_\bW_\bN_\b*.
+
+       _\bm_\bi_\bn and _\bm_\ba_\bx define the expected range values for data supplied by a
+       data source. If _\bm_\bi_\bn and/or _\bm_\ba_\bx any value outside the defined range will
+       be regarded as _\b*_\bU_\bN_\bK_\bN_\bO_\bW_\bN_\b*. If you do not know or care about min and max,
+       set them to U for unknown. Note that min and max always refer to the
+       processed values of the DS. For a traffic-C\bCO\bOU\bUN\bNT\bTE\bER\bR type DS this would be
+       the maximum and minimum data-rate expected from the device.
+
+       _\bI_\bf _\bi_\bn_\bf_\bo_\br_\bm_\ba_\bt_\bi_\bo_\bn _\bo_\bn _\bm_\bi_\bn_\bi_\bm_\ba_\bl_\b/_\bm_\ba_\bx_\bi_\bm_\ba_\bl _\be_\bx_\bp_\be_\bc_\bt_\be_\bd _\bv_\ba_\bl_\bu_\be_\bs _\bi_\bs _\ba_\bv_\ba_\bi_\bl_\ba_\bb_\bl_\be_\b, _\ba_\bl_\bw_\ba_\by_\bs
+       _\bs_\be_\bt _\bt_\bh_\be _\bm_\bi_\bn _\ba_\bn_\bd_\b/_\bo_\br _\bm_\ba_\bx _\bp_\br_\bo_\bp_\be_\br_\bt_\bi_\be_\bs_\b. _\bT_\bh_\bi_\bs _\bw_\bi_\bl_\bl _\bh_\be_\bl_\bp _\bR_\bR_\bD_\bt_\bo_\bo_\bl _\bi_\bn _\bd_\bo_\bi_\bn_\bg _\ba
+       _\bs_\bi_\bm_\bp_\bl_\be _\bs_\ba_\bn_\bi_\bt_\by _\bc_\bh_\be_\bc_\bk _\bo_\bn _\bt_\bh_\be _\bd_\ba_\bt_\ba _\bs_\bu_\bp_\bp_\bl_\bi_\be_\bd _\bw_\bh_\be_\bn _\br_\bu_\bn_\bn_\bi_\bn_\bg _\bu_\bp_\bd_\ba_\bt_\be_\b.
+
+       _\br_\bp_\bn_\b-_\be_\bx_\bp_\br_\be_\bs_\bs_\bi_\bo_\bn defines the formula used to compute the PDPs of a
+       COMPUTE data source from other data sources in the same <RRD>. It is
+       similar to defining a C\bCD\bDE\bEF\bF argument for the graph command. Please refer
+       to that manual page for a list and description of RPN operations
+       supported. For COMPUTE data sources, the following RPN operations are
+       not supported: COUNT, PREV, TIME, and LTIME. In addition, in defining
+       the RPN expression, the COMPUTE data source may only refer to the names
+       of data source listed previously in the create command. This is similar
+       to the restriction that C\bCD\bDE\bEF\bFs must refer only to D\bDE\bEF\bFs and C\bCD\bDE\bEF\bFs
+       previously defined in the same graph command.
+
+   R\bRR\bRA\bA:\b:_\bC_\bF:\b:_\bc_\bf _\ba_\br_\bg_\bu_\bm_\be_\bn_\bt_\bs
+       The purpose of an R\bRR\bRD\bD is to store data in the round robin archives
+       (R\bRR\bRA\bA). An archive consists of a number of data values or statistics for
+       each of the defined data-sources (D\bDS\bS) and is defined with an R\bRR\bRA\bA line.
+
+       When data is entered into an R\bRR\bRD\bD, it is first fit into time slots of
+       the length defined with the -\b-s\bs option, thus becoming a _\bp_\br_\bi_\bm_\ba_\br_\by _\bd_\ba_\bt_\ba
+       _\bp_\bo_\bi_\bn_\bt.
+
+       The data is also processed with the consolidation function (_\bC_\bF) of the
+       archive. There are several consolidation functions that consolidate
+       primary data points via an aggregate function: A\bAV\bVE\bER\bRA\bAG\bGE\bE, M\bMI\bIN\bN, M\bMA\bAX\bX, L\bLA\bAS\bST\bT.
+
+       AVERAGE
+           the average of the data points is stored.
+
+       MIN the smallest of the data points is stored.
+
+       MAX the largest of the data points is stored.
+
+       LAST
+           the last data points is used.
+
+       Note that data aggregation inevitably leads to loss of precision and
+       information. The trick is to pick the aggregate function such that the
+       _\bi_\bn_\bt_\be_\br_\be_\bs_\bt_\bi_\bn_\bg properties of your data is kept across the aggregation
+       process.
+
+       The format of R\bRR\bRA\bA line for these consolidation functions is:
+
+       R\bRR\bRA\bA:\b:_\bA_\bV_\bE_\bR_\bA_\bG_\bE _\b| _\bM_\bI_\bN _\b| _\bM_\bA_\bX _\b| _\bL_\bA_\bS_\bT:\b:_\bx_\bf_\bf:\b:_\bs_\bt_\be_\bp_\bs:\b:_\br_\bo_\bw_\bs
+
+       _\bx_\bf_\bf The xfiles factor defines what part of a consolidation interval may
+       be made up from _\b*_\bU_\bN_\bK_\bN_\bO_\bW_\bN_\b* data while the consolidated value is still
+       regarded as known. It is given as the ratio of allowed _\b*_\bU_\bN_\bK_\bN_\bO_\bW_\bN_\b* PDPs
+       to the number of PDPs in the interval. Thus, it ranges from 0 to 1
+       (exclusive).
+
+       _\bs_\bt_\be_\bp_\bs defines how many of these _\bp_\br_\bi_\bm_\ba_\br_\by _\bd_\ba_\bt_\ba _\bp_\bo_\bi_\bn_\bt_\bs are used to build a
+       _\bc_\bo_\bn_\bs_\bo_\bl_\bi_\bd_\ba_\bt_\be_\bd _\bd_\ba_\bt_\ba _\bp_\bo_\bi_\bn_\bt which then goes into the archive.
+
+       _\br_\bo_\bw_\bs defines how many generations of data values are kept in an R\bRR\bRA\bA.
+       Obviously, this has to be greater than zero.
 
 A\bAb\bbe\ber\brr\bra\ban\bnt\bt B\bBe\beh\bha\bav\bvi\bio\bor\br D\bDe\bet\bte\bec\bct\bti\bio\bon\bn w\bwi\bit\bth\bh H\bHo\bol\blt\bt-\b-W\bWi\bin\bnt\bte\ber\brs\bs F\bFo\bor\bre\bec\bca\bas\bst\bti\bin\bng\bg
        In addition to the aggregate functions, there are a set of specialized
@@ -208,11 +192,11 @@ A\bAb\bbe\ber\brr\bra\ban\bnt\bt B\bBe\beh\bha\bav\bvi\bio\bor\br D\bDe\bet\bte\bec\bct\bti\bio\bon\bn w\b
 
        ยท   R\bRR\bRA\bA:\b:_\bM_\bH_\bW_\bP_\bR_\bE_\bD_\bI_\bC_\bT:\b:_\br_\bo_\bw_\bs:\b:_\ba_\bl_\bp_\bh_\ba:\b:_\bb_\be_\bt_\ba:\b:_\bs_\be_\ba_\bs_\bo_\bn_\ba_\bl _\bp_\be_\br_\bi_\bo_\bd[:\b:_\br_\br_\ba_\b-_\bn_\bu_\bm]
 
-       ยท   R\bRR\bRA\bA:\b:_\bS_\bE_\bA_\bS_\bO_\bN_\bA_\bL:\b:_\bs_\be_\ba_\bs_\bo_\bn_\ba_\bl _\bp_\be_\br_\bi_\bo_\bd:\b:_\bg_\ba_\bm_\bm_\ba:\b:_\br_\br_\ba_\b-_\bn_\bu_\bm[:\b:s\bsm\bmo\boo\bot\bth\bhi\bin\bng\bg-\b-w\bwi\bin\bnd\bdo\bow\bw=\b=_\bf_\br_\ba_\bc_\b-
-           _\bt_\bi_\bo_\bn]
+       ยท   R\bRR\bRA\bA:\b:_\bS_\bE_\bA_\bS_\bO_\bN_\bA_\bL:\b:_\bs_\be_\ba_\bs_\bo_\bn_\ba_\bl _\bp_\be_\br_\bi_\bo_\bd:\b:_\bg_\ba_\bm_\bm_\ba:\b:_\br_\br_\ba_\b-
+           _\bn_\bu_\bm[:\b:s\bsm\bmo\boo\bot\bth\bhi\bin\bng\bg-\b-w\bwi\bin\bnd\bdo\bow\bw=\b=_\bf_\br_\ba_\bc_\bt_\bi_\bo_\bn]
 
-       ยท   R\bRR\bRA\bA:\b:_\bD_\bE_\bV_\bS_\bE_\bA_\bS_\bO_\bN_\bA_\bL:\b:_\bs_\be_\ba_\bs_\bo_\bn_\ba_\bl _\bp_\be_\br_\bi_\bo_\bd:\b:_\bg_\ba_\bm_\bm_\ba:\b:_\br_\br_\ba_\b-_\bn_\bu_\bm[:\b:s\bsm\bmo\boo\bot\bth\bhi\bin\bng\bg-\b-w\bwi\bin\bn-\b-
-           d\bdo\bow\bw=\b=_\bf_\br_\ba_\bc_\bt_\bi_\bo_\bn]
+       ยท   R\bRR\bRA\bA:\b:_\bD_\bE_\bV_\bS_\bE_\bA_\bS_\bO_\bN_\bA_\bL:\b:_\bs_\be_\ba_\bs_\bo_\bn_\ba_\bl _\bp_\be_\br_\bi_\bo_\bd:\b:_\bg_\ba_\bm_\bm_\ba:\b:_\br_\br_\ba_\b-
+           _\bn_\bu_\bm[:\b:s\bsm\bmo\boo\bot\bth\bhi\bin\bng\bg-\b-w\bwi\bin\bnd\bdo\bow\bw=\b=_\bf_\br_\ba_\bc_\bt_\bi_\bo_\bn]
 
        ยท   R\bRR\bRA\bA:\b:_\bD_\bE_\bV_\bP_\bR_\bE_\bD_\bI_\bC_\bT:\b:_\br_\bo_\bw_\bs:\b:_\br_\br_\ba_\b-_\bn_\bu_\bm
 
@@ -222,25 +206,25 @@ A\bAb\bbe\ber\brr\bra\ban\bnt\bt B\bBe\beh\bha\bav\bvi\bio\bor\br D\bDe\bet\bte\bec\bct\bti\bio\bon\bn w\b
        ways.  First, each of the R\bRR\bRA\bAs is updated once for every primary data
        point.  Second, these R\bRR\bRA\bAs\bs are interdependent. To generate real-time
        confidence bounds, a matched set of SEASONAL, DEVSEASONAL, DEVPREDICT,
-       and either HWPREDICT or MHWPREDICT must exist. Generating smoothed val-
-       ues of the primary data points requires a SEASONAL R\bRR\bRA\bA and either an
-       HWPREDICT or MHWPREDICT R\bRR\bRA\bA. Aberrant behavior detection requires FAIL-
-       URES, DEVSEASONAL, SEASONAL, and either HWPREDICT or MHWPREDICT.
+       and either HWPREDICT or MHWPREDICT must exist. Generating smoothed
+       values of the primary data points requires a SEASONAL R\bRR\bRA\bA and either an
+       HWPREDICT or MHWPREDICT R\bRR\bRA\bA. Aberrant behavior detection requires
+       FAILURES, DEVSEASONAL, SEASONAL, and either HWPREDICT or MHWPREDICT.
 
-       The predicted, or smoothed, values are stored in the HWPREDICT or MHW-
-       PREDICT R\bRR\bRA\bA. HWPREDICT and MHWPREDICT are actually two variations on
+       The predicted, or smoothed, values are stored in the HWPREDICT or
+       MHWPREDICT R\bRR\bRA\bA. HWPREDICT and MHWPREDICT are actually two variations on
        the Holt-Winters method. They are interchangeable. Both attempt to
-       decompose data into three components: a baseline, a trend, and a sea-
-       sonal coefficient.  HWPREDICT adds its seasonal coefficient to the
-       baseline to form a prediction, whereas MHWPREDICT multiplies its sea-
-       sonal coefficient by the baseline to form a prediction. The difference
-       is noticeable when the baseline changes significantly in the course of
-       a season; HWPREDICT will predict the seasonality to stay constant as
-       the baseline changes, but MHWPREDICT will predict the seasonality to
-       grow or shrink in proportion to the baseline. The proper choice of
-       method depends on the thing being modeled. For simplicity, the rest of
-       this discussion will refer to HWPREDICT, but MHWPREDICT may be substi-
-       tuted in its place.
+       decompose data into three components: a baseline, a trend, and a
+       seasonal coefficient.  HWPREDICT adds its seasonal coefficient to the
+       baseline to form a prediction, whereas MHWPREDICT multiplies its
+       seasonal coefficient by the baseline to form a prediction. The
+       difference is noticeable when the baseline changes significantly in the
+       course of a season; HWPREDICT will predict the seasonality to stay
+       constant as the baseline changes, but MHWPREDICT will predict the
+       seasonality to grow or shrink in proportion to the baseline. The proper
+       choice of method depends on the thing being modeled. For simplicity,
+       the rest of this discussion will refer to HWPREDICT, but MHWPREDICT may
+       be substituted in its place.
 
        The predicted deviations are stored in DEVPREDICT (think a standard
        deviation which can be scaled to yield a confidence band). The FAILURES
@@ -254,8 +238,8 @@ A\bAb\bbe\ber\brr\bra\ban\bnt\bt B\bBe\beh\bha\bav\bvi\bio\bor\br D\bDe\bet\bte\bec\bct\bti\bio\bon\bn w\b
        the Holt-Winters forecasting algorithm and the seasonal deviations,
        respectively.  There is one entry per observation time point in the
        seasonal cycle. For example, if primary data points are generated every
-       five minutes and the seasonal cycle is 1 day, both SEASONAL and DEVSEA-
-       SONAL will have 288 rows.
+       five minutes and the seasonal cycle is 1 day, both SEASONAL and
+       DEVSEASONAL will have 288 rows.
 
        In order to simplify the creation for the novice user, in addition to
        supporting explicit creation of the HWPREDICT, SEASONAL, DEVPREDICT,
@@ -268,46 +252,46 @@ A\bAb\bbe\ber\brr\bra\ban\bnt\bt B\bBe\beh\bha\bav\bvi\bio\bor\br D\bDe\bet\bte\bec\bct\bti\bio\bon\bn w\b
        and entries in these RRAs. For the HWPREDICT CF, _\br_\bo_\bw_\bs should be larger
        than the _\bs_\be_\ba_\bs_\bo_\bn_\ba_\bl _\bp_\be_\br_\bi_\bo_\bd. If the DEVPREDICT R\bRR\bRA\bA is implicitly created,
        the default number of rows is the same as the HWPREDICT _\br_\bo_\bw_\bs argument.
-       If the FAILURES R\bRR\bRA\bA is implicitly created, _\br_\bo_\bw_\bs will be set to the _\bs_\be_\ba_\b-
-       _\bs_\bo_\bn_\ba_\bl _\bp_\be_\br_\bi_\bo_\bd argument of the HWPREDICT R\bRR\bRA\bA. Of course, the R\bRR\bRD\bDt\bto\boo\bol\bl
+       If the FAILURES R\bRR\bRA\bA is implicitly created, _\br_\bo_\bw_\bs will be set to the
+       _\bs_\be_\ba_\bs_\bo_\bn_\ba_\bl _\bp_\be_\br_\bi_\bo_\bd argument of the HWPREDICT R\bRR\bRA\bA. Of course, the R\bRR\bRD\bDt\bto\boo\bol\bl
        _\br_\be_\bs_\bi_\bz_\be command is available if these defaults are not sufficient and
        the creator wishes to avoid explicit creations of the other specialized
        function R\bRR\bRA\bAs\bs.
 
-       _\bs_\be_\ba_\bs_\bo_\bn_\ba_\bl _\bp_\be_\br_\bi_\bo_\bd specifies the number of primary data points in a sea-
-       sonal cycle. If SEASONAL and DEVSEASONAL are implicitly created, this
-       argument for those R\bRR\bRA\bAs\bs is set automatically to the value specified by
-       HWPREDICT. If they are explicitly created, the creator should verify
-       that all three _\bs_\be_\ba_\bs_\bo_\bn_\ba_\bl _\bp_\be_\br_\bi_\bo_\bd arguments agree.
-
-       _\ba_\bl_\bp_\bh_\ba is the adaption parameter of the intercept (or baseline) coeffi-
-       cient in the Holt-Winters forecasting algorithm. See rrdtool for a
-       description of this algorithm. _\ba_\bl_\bp_\bh_\ba must lie between 0 and 1. A value
-       closer to 1 means that more recent observations carry greater weight in
-       predicting the baseline component of the forecast. A value closer to 0
-       means that past history carries greater weight in predicting the base-
-       line component.
-
-       _\bb_\be_\bt_\ba is the adaption parameter of the slope (or linear trend) coeffi-
-       cient in the Holt-Winters forecasting algorithm. _\bb_\be_\bt_\ba must lie between
-       0 and 1 and plays the same role as _\ba_\bl_\bp_\bh_\ba with respect to the predicted
-       linear trend.
+       _\bs_\be_\ba_\bs_\bo_\bn_\ba_\bl _\bp_\be_\br_\bi_\bo_\bd specifies the number of primary data points in a
+       seasonal cycle. If SEASONAL and DEVSEASONAL are implicitly created,
+       this argument for those R\bRR\bRA\bAs\bs is set automatically to the value
+       specified by HWPREDICT. If they are explicitly created, the creator
+       should verify that all three _\bs_\be_\ba_\bs_\bo_\bn_\ba_\bl _\bp_\be_\br_\bi_\bo_\bd arguments agree.
+
+       _\ba_\bl_\bp_\bh_\ba is the adaption parameter of the intercept (or baseline)
+       coefficient in the Holt-Winters forecasting algorithm. See rrdtool for
+       a description of this algorithm. _\ba_\bl_\bp_\bh_\ba must lie between 0 and 1. A
+       value closer to 1 means that more recent observations carry greater
+       weight in predicting the baseline component of the forecast. A value
+       closer to 0 means that past history carries greater weight in
+       predicting the baseline component.
+
+       _\bb_\be_\bt_\ba is the adaption parameter of the slope (or linear trend)
+       coefficient in the Holt-Winters forecasting algorithm. _\bb_\be_\bt_\ba must lie
+       between 0 and 1 and plays the same role as _\ba_\bl_\bp_\bh_\ba with respect to the
+       predicted linear trend.
 
        _\bg_\ba_\bm_\bm_\ba is the adaption parameter of the seasonal coefficients in the
-       Holt-Winters forecasting algorithm (HWPREDICT) or the adaption parame-
-       ter in the exponential smoothing update of the seasonal deviations. It
-       must lie between 0 and 1. If the SEASONAL and DEVSEASONAL R\bRR\bRA\bAs\bs are cre-
-       ated implicitly, they will both have the same value for _\bg_\ba_\bm_\bm_\ba: the
-       value specified for the HWPREDICT _\ba_\bl_\bp_\bh_\ba argument. Note that because
-       there is one seasonal coefficient (or deviation) for each time point
-       during the seasonal cycle, the adaptation rate is much slower than the
-       baseline. Each seasonal coefficient is only updated (or adapts) when
-       the observed value occurs at the offset in the seasonal cycle corre-
-       sponding to that coefficient.
+       Holt-Winters forecasting algorithm (HWPREDICT) or the adaption
+       parameter in the exponential smoothing update of the seasonal
+       deviations. It must lie between 0 and 1. If the SEASONAL and
+       DEVSEASONAL R\bRR\bRA\bAs\bs are created implicitly, they will both have the same
+       value for _\bg_\ba_\bm_\bm_\ba: the value specified for the HWPREDICT _\ba_\bl_\bp_\bh_\ba argument.
+       Note that because there is one seasonal coefficient (or deviation) for
+       each time point during the seasonal cycle, the adaptation rate is much
+       slower than the baseline. Each seasonal coefficient is only updated (or
+       adapts) when the observed value occurs at the offset in the seasonal
+       cycle corresponding to that coefficient.
 
        If SEASONAL and DEVSEASONAL R\bRR\bRA\bAs\bs are created explicitly, _\bg_\ba_\bm_\bm_\ba need not
-       be the same for both. Note that _\bg_\ba_\bm_\bm_\ba can also be changed via the R\bRR\bRD\bD-\b-
-       t\bto\boo\bol\bl _\bt_\bu_\bn_\be command.
+       be the same for both. Note that _\bg_\ba_\bm_\bm_\ba can also be changed via the
+       R\bRR\bRD\bDt\bto\boo\bol\bl _\bt_\bu_\bn_\be command.
 
        _\bs_\bm_\bo_\bo_\bt_\bh_\bi_\bn_\bg_\b-_\bw_\bi_\bn_\bd_\bo_\bw specifies the fraction of a season that should be
        averaged around each point. By default, the value of _\bs_\bm_\bo_\bo_\bt_\bh_\bi_\bn_\bg_\b-_\bw_\bi_\bn_\bd_\bo_\bw
@@ -316,14 +300,15 @@ A\bAb\bbe\ber\brr\bra\ban\bnt\bt B\bBe\beh\bha\bav\bvi\bio\bor\br D\bDe\bet\bte\bec\bct\bti\bio\bon\bn w\b
        nearest neighbors.  Setting _\bs_\bm_\bo_\bo_\bt_\bh_\bi_\bn_\bg_\b-_\bw_\bi_\bn_\bd_\bo_\bw to zero will disable the
        running-average smoother altogether.
 
-       _\br_\br_\ba_\b-_\bn_\bu_\bm provides the links between related R\bRR\bRA\bAs\bs. If HWPREDICT is speci-
-       fied alone and the other R\bRR\bRA\bAs\bs are created implicitly, then there is no
-       need to worry about this argument. If R\bRR\bRA\bAs\bs are created explicitly, then
-       carefully pay attention to this argument. For each R\bRR\bRA\bA which includes
-       this argument, there is a dependency between that R\bRR\bRA\bA and another R\bRR\bRA\bA.
-       The _\br_\br_\ba_\b-_\bn_\bu_\bm argument is the 1-based index in the order of R\bRR\bRA\bA creation
-       (that is, the order they appear in the _\bc_\br_\be_\ba_\bt_\be command). The dependent
-       R\bRR\bRA\bA for each R\bRR\bRA\bA requiring the _\br_\br_\ba_\b-_\bn_\bu_\bm argument is listed here:
+       _\br_\br_\ba_\b-_\bn_\bu_\bm provides the links between related R\bRR\bRA\bAs\bs. If HWPREDICT is
+       specified alone and the other R\bRR\bRA\bAs\bs are created implicitly, then there
+       is no need to worry about this argument. If R\bRR\bRA\bAs\bs are created
+       explicitly, then carefully pay attention to this argument. For each R\bRR\bRA\bA
+       which includes this argument, there is a dependency between that R\bRR\bRA\bA
+       and another R\bRR\bRA\bA. The _\br_\br_\ba_\b-_\bn_\bu_\bm argument is the 1-based index in the order
+       of R\bRR\bRA\bA creation (that is, the order they appear in the _\bc_\br_\be_\ba_\bt_\be command).
+       The dependent R\bRR\bRA\bA for each R\bRR\bRA\bA requiring the _\br_\br_\ba_\b-_\bn_\bu_\bm argument is listed
+       here:
 
        ยท   HWPREDICT _\br_\br_\ba_\b-_\bn_\bu_\bm is the index of the SEASONAL R\bRR\bRA\bA.
 
@@ -341,9 +326,9 @@ A\bAb\bbe\ber\brr\bra\ban\bnt\bt B\bBe\beh\bha\bav\bvi\bio\bor\br D\bDe\bet\bte\bec\bct\bti\bio\bon\bn w\b
 
        _\bw_\bi_\bn_\bd_\bo_\bw _\bl_\be_\bn_\bg_\bt_\bh is the number of time points in the window. Specify an
        integer greater than or equal to the threshold and less than or equal
-       to 28.  The time interval this window represents depends on the inter-
-       val between primary data points. If the FAILURES R\bRR\bRA\bA is implicitly cre-
-       ated, the default value is 9.
+       to 28.  The time interval this window represents depends on the
+       interval between primary data points. If the FAILURES R\bRR\bRA\bA is implicitly
+       created, the default value is 9.
 
 T\bTh\bhe\be H\bHE\bEA\bAR\bRT\bTB\bBE\bEA\bAT\bT a\ban\bnd\bd t\bth\bhe\be S\bST\bTE\bEP\bP
        Here is an explanation by Don Baarda on the inner workings of RRDtool.
@@ -354,13 +339,14 @@ T\bTh\bhe\be H\bHE\bEA\bAR\bRT\bTB\bBE\bEA\bAT\bT a\ban\bnd\bd t\bth\bhe\be S\bST\bTE\bEP\bP
        builds Primary Data Points (PDPs) on every "step" interval. The PDPs
        are then accumulated into the RRAs.
 
-       The "heartbeat" defines the maximum acceptable interval between sam-
-       ples/updates. If the interval between samples is less than "heartbeat",
-       then an average rate is calculated and applied for that interval. If
-       the interval between samples is longer than "heartbeat", then that
-       entire interval is considered "unknown". Note that there are other
-       things that can make a sample interval "unknown", such as the rate
-       exceeding limits, or a sample that was explicitly marked as unknown.
+       The "heartbeat" defines the maximum acceptable interval between
+       samples/updates. If the interval between samples is less than
+       "heartbeat", then an average rate is calculated and applied for that
+       interval. If the interval between samples is longer than "heartbeat",
+       then that entire interval is considered "unknown". Note that there are
+       other things that can make a sample interval "unknown", such as the
+       rate exceeding limits, or a sample that was explicitly marked as
+       unknown.
 
        The known rates during a PDP's "step" interval are used to calculate an
        average rate for that PDP. If the total "unknown" time accounts for
@@ -374,10 +360,10 @@ T\bTh\bhe\be H\bHE\bEA\bAR\bRT\bTB\bBE\bEA\bAT\bT a\ban\bnd\bd t\bth\bhe\be S\bST\bTE\bEP\bP
        multiple samples per PDP, and if you don't get them mark the PDP
        unknown. A long heartbeat can span multiple "steps", which means it is
        acceptable to have multiple PDPs calculated from a single sample. An
-       extreme example of this might be a "step" of 5 minutes and a "heart-
-       beat" of one day, in which case a single sample every day will result
-       in all the PDPs for that entire day period being set to the same aver-
-       age rate. _\b-_\b- _\bD_\bo_\bn _\bB_\ba_\ba_\br_\bd_\ba _\b<_\bd_\bo_\bn_\b._\bb_\ba_\ba_\br_\bd_\ba_\b@_\bb_\ba_\be_\bs_\by_\bs_\bt_\be_\bm_\bs_\b._\bc_\bo_\bm_\b>
+       extreme example of this might be a "step" of 5 minutes and a
+       "heartbeat" of one day, in which case a single sample every day will
+       result in all the PDPs for that entire day period being set to the same
+       average rate. _\b-_\b- _\bD_\bo_\bn _\bB_\ba_\ba_\br_\bd_\ba _\b<_\bd_\bo_\bn_\b._\bb_\ba_\ba_\br_\bd_\ba_\b@_\bb_\ba_\be_\bs_\by_\bs_\bt_\be_\bm_\bs_\b._\bc_\bo_\bm_\b>
 
               time|
               axis|
@@ -421,28 +407,28 @@ H\bHO\bOW\bW T\bTO\bO M\bME\bEA\bAS\bSU\bUR\bRE\bE
        Here are a few hints on how to measure:
 
        Temperature
-           Usually you have some type of meter you can read to get the temper-
-           ature.  The temperature is not really connected with a time. The
-           only connection is that the temperature reading happened at a cer-
-           tain time. You can use the G\bGA\bAU\bUG\bGE\bE data source type for this. RRDtool
-           will then record your reading together with the time.
+           Usually you have some type of meter you can read to get the
+           temperature.  The temperature is not really connected with a time.
+           The only connection is that the temperature reading happened at a
+           certain time. You can use the G\bGA\bAU\bUG\bGE\bE data source type for this.
+           RRDtool will then record your reading together with the time.
 
        Mail Messages
-           Assume you have a method to count the number of messages trans-
-           ported by your mailserver in a certain amount of time, giving you
-           data like '5 messages in the last 65 seconds'. If you look at the
-           count of 5 like an A\bAB\bBS\bSO\bOL\bLU\bUT\bTE\bE data type you can simply update the RRD
-           with the number 5 and the end time of your monitoring period. RRD-
-           tool will then record the number of messages per second. If at some
-           later stage you want to know the number of messages transported in
-           a day, you can get the average messages per second from RRDtool for
-           the day in question and multiply this number with the number of
-           seconds in a day. Because all math is run with Doubles, the preci-
-           sion should be acceptable.
+           Assume you have a method to count the number of messages
+           transported by your mailserver in a certain amount of time, giving
+           you data like '5 messages in the last 65 seconds'. If you look at
+           the count of 5 like an A\bAB\bBS\bSO\bOL\bLU\bUT\bTE\bE data type you can simply update the
+           RRD with the number 5 and the end time of your monitoring period.
+           RRDtool will then record the number of messages per second. If at
+           some later stage you want to know the number of messages
+           transported in a day, you can get the average messages per second
+           from RRDtool for the day in question and multiply this number with
+           the number of seconds in a day. Because all math is run with
+           Doubles, the precision should be acceptable.
 
        It's always a Rate
-           RRDtool stores rates in amount/second for COUNTER, DERIVE and ABSO-
-           LUTE data.  When you plot the data, you will get on the y axis
+           RRDtool stores rates in amount/second for COUNTER, DERIVE and
+           ABSOLUTE data.  When you plot the data, you will get on the y axis
            amount/second which you might be tempted to convert to an absolute
            amount by multiplying by the delta-time between the points. RRDtool
            plots continuous data, and as such is not appropriate for plotting
@@ -462,17 +448,17 @@ E\bEX\bXA\bAM\bMP\bPL\bLE\bE
          RRA:MAX:0.5:12:2400 \
          RRA:AVERAGE:0.5:12:2400
 
-       This sets up an R\bRR\bRD\bD called _\bt_\be_\bm_\bp_\be_\br_\ba_\bt_\bu_\br_\be_\b._\br_\br_\bd which accepts one tempera-
-       ture value every 300 seconds. If no new data is supplied for more than
-       600 seconds, the temperature becomes _\b*_\bU_\bN_\bK_\bN_\bO_\bW_\bN_\b*.  The minimum acceptable
-       value is -273 and the maximum is 5'000.
+       This sets up an R\bRR\bRD\bD called _\bt_\be_\bm_\bp_\be_\br_\ba_\bt_\bu_\br_\be_\b._\br_\br_\bd which accepts one
+       temperature value every 300 seconds. If no new data is supplied for
+       more than 600 seconds, the temperature becomes _\b*_\bU_\bN_\bK_\bN_\bO_\bW_\bN_\b*.  The minimum
+       acceptable value is -273 and the maximum is 5'000.
 
        A few archive areas are also defined. The first stores the temperatures
        supplied for 100 hours (1'200 * 300 seconds = 100 hours). The second
        RRA stores the minimum temperature recorded over every hour (12 * 300
        seconds = 1 hour), for 100 days (2'400 hours). The third and the fourth
-       RRA's do the same for the maximum and average temperature, respec-
-       tively.
+       RRA's do the same for the maximum and average temperature,
+       respectively.
 
 E\bEX\bXA\bAM\bMP\bPL\bLE\bE 2\b2
         rrdtool create monitor.rrd --step 300        \
@@ -486,18 +472,18 @@ E\bEX\bXA\bAM\bMP\bPL\bLE\bE 2\b2
        argument of HWPREDICT is missing, so the other R\bRR\bRA\bAs\bs will implicitly be
        created with default parameter values. In this example, the forecasting
        algorithm baseline adapts quickly; in fact the most recent one hour of
-       observations (each at 5 minute intervals) accounts for 75% of the base-
-       line prediction. The linear trend forecast adapts much more slowly.
+       observations (each at 5 minute intervals) accounts for 75% of the
+       baseline prediction. The linear trend forecast adapts much more slowly.
        Observations made during the last day (at 288 observations per day)
-       account for only 65% of the predicted linear trend. Note: these compu-
-       tations rely on an exponential smoothing formula described in the LISA
-       2000 paper.
+       account for only 65% of the predicted linear trend. Note: these
+       computations rely on an exponential smoothing formula described in the
+       LISA 2000 paper.
 
-       The seasonal cycle is one day (288 data points at 300 second inter-
-       vals), and the seasonal adaption parameter will be set to 0.1. The RRD
-       file will store 5 days (1'440 data points) of forecasts and deviation
-       predictions before wrap around. The file will store 1 day (a seasonal
-       cycle) of 0-1 indicators in the FAILURES R\bRR\bRA\bA.
+       The seasonal cycle is one day (288 data points at 300 second
+       intervals), and the seasonal adaption parameter will be set to 0.1. The
+       RRD file will store 5 days (1'440 data points) of forecasts and
+       deviation predictions before wrap around. The file will store 1 day (a
+       seasonal cycle) of 0-1 indicators in the FAILURES R\bRR\bRA\bA.
 
        The same RRD file and R\bRR\bRA\bAs\bs are created with the following command,
        which explicitly creates all specialized function R\bRR\bRA\bAs\bs.
@@ -511,8 +497,8 @@ E\bEX\bXA\bAM\bMP\bPL\bLE\bE 2\b2
           RRA:DEVSEASONAL:288:0.1:2 \
           RRA:FAILURES:288:7:9:5
 
-       Of course, explicit creation need not replicate implicit create, a num-
-       ber of arguments could be changed.
+       Of course, explicit creation need not replicate implicit create, a
+       number of arguments could be changed.
 
 E\bEX\bXA\bAM\bMP\bPL\bLE\bE 3\b3
         rrdtool create proxy.rrd --step 300 \
@@ -531,14 +517,15 @@ E\bEX\bXA\bAM\bMP\bPL\bLE\bE 3\b3
 
        In the R\bRR\bRD\bD, the first data source stores the requests per second rate
        during the interval. The second data source stores the total duration
-       of all requests processed during the interval divided by 300. The COM-
-       PUTE data source divides each PDP of the AccumDuration by the corre-
-       sponding PDP of TotalRequests and stores the average request duration.
-       The remainder of the RPN expression handles the divide by zero case.
+       of all requests processed during the interval divided by 300. The
+       COMPUTE data source divides each PDP of the AccumDuration by the
+       corresponding PDP of TotalRequests and stores the average request
+       duration. The remainder of the RPN expression handles the divide by
+       zero case.
 
 A\bAU\bUT\bTH\bHO\bOR\bR
        Tobias Oetiker <tobi@oetiker.ch>
 
 
 
-1.3rc4                            2008-05-12                      RRDCREATE(1)
+1.3.8                             2008-06-11                      RRDCREATE(1)