I monitor traffic and bandwidth usage in my network with several sensors. In the data tables of these sensors, I can see a volume and a speed value, but in the sensor graphs, PRTG shows only speed values. Why doesn’t PRTG show the volume in data graphs?
This article applies to PRTG Network Monitor 13 or later
Graphs without Volume Lines
Sensor types that can be referred to as Delta Sensors do not include volume in their data graphs, neither in live graphs nor in historical data graphs. Delta sensors are, for example, sensor types that monitor traffic and bandwidth usage like the SNMP Traffic sensor, the SNMP RMON sensor, or NetFlow sensors. They show the volume value only in data tables, while speed additionally appears in the data graphs.
Volume is the latest retrieved value and speed is the averaged volume during the last scanning interval:
speed = volume / scanning interval in seconds
For example, if the value for volume is 6.000 # (total number of packets) after the last scan, then speed is 100 #/s (packets per second) with a scanning interval of 60 seconds.
Why There Is No Volume in Graphs
In PRTG, the x-axis in graphs indicates the time of the sensor scans. It is the “time line” of the sensor’s data history so PRTG displays all data in graphs based on linear time. If all sensor measurements would have the same time interval (e.g., 60 seconds), volume and speed graphs would have a linear conversion and their graph lines would always be the match each other.
However, sensor scans most likely do not happen so regularly, for example, if you use Check Now for an extra measurement or the sensor missed a value because of a timeout. In this case, speed and volume do not convert linear and causes issues for a time-based graph. For volume display, there are two options:
- If the graph displays the values as they are, the line for volume would have dents and peaks. This would visually indicate that there was a change of the volume, although the speed (i.e., the averaged volume) stayed the same.
- If we would adjust the volume to the time, the graph points would not match the values in the data table and would be the same as the speed graph but with a different label.
Both ways would cause confusion because always someone would expect that the behavior was different. The only way to display delta sensor graphs mathematically and visually correctly is to use the speed value.
Consider a printer that constantly prints 10 pages per minute. Looking at the volume that is measured in a default scanning interval of 60 seconds, we would have the following values:
|Time||Value (number of pages)|
The resulting graph would show a straight line for the volume:
But if there are any irregularities in the scanning interval, e.g., an extra scan via “Check Now” or even editing device settings might be enough to cause them, the measured volumes could look like this:
|Time||Value (number of page)|
This results in a volume graph with a curved line that will not let you recognize any peaks:
Displaying the measured values as speed averages the volume to time. For the sample volumes from above, this results in the following speed values:
|Time||Value (pages per minute)|
So you get a straight line again in the graph, making it easy to recognize peaks or dents: