Lab Tip: Absolute vs Delta

If you’ve ever come across a RMON task in a practice lab, you probably find that the hardest part of the configuration is determining whether the value being measured is a delta (change over time) or an absolute value.  You could get the configuration completely correct except that you chose the wrong measurement option (I’ve done it plenty of times).

A recent email on the GroupStudy list defined the difference between these two modes very succinctly and very well:

Delta : For values that always increase
Absolute : For values that can increase or decrease

CPU utilization can go up or down (0% to 100%) so it would be an absolute value.  Packets entering an interface will always accumulate (until the counters are cleared) so this would be a delta value.  We’re (more likely to be*) interested in the number of packets during a certain interval (say the last 5 minutes) instead of the total number of packets since the counters were last cleared.

One of the ways that I determine whether to use absolute or delta is whether or not the “falling-threshold” can be attained.  If a task has you configure a falling-threshold that cannot be reached (after the rising-threshold has been met) then I choose to use ‘delta’.  For instance, if the task is referring to inbound packets (a value that always increases) and has a rising-threshold of 100 and a falling-threshold of 50, you can use ‘absolute’ but once the rising threshold is breached, the falling-threshold cannot be attained (unless the counters are cleared).  This is either a poorly written task…or more likely you should use ‘delta’.

*Sure, we could monitor the absolute value of packets and generate an alarm when packets reach  certain value (say 1 million) but that’s a pretty strange/ineffective alarm.