Please see this same question (with pictures) as originally posted here: https://devcentral.f5.com/questions/am-i-calculating-total-throughput-correctly-on-my-ltm

Question:

I am attempting to calculate the total throughput on my F5-Big-LTM-3600-4G-R with PRTG via SNMP queries and my own calculations.

I have used the "Collecting data on throughput" section in this post as a reference: http://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip9_0sys/9_0_xSystemMgmtGuide-12-1.html The part of this article that I do not understand is what values in bytes the OIDs they are using are actually providing, and what the "time" value would be that they are suggesting to divide by.

For reference, here are the OIDs that I am using and their names and descriptions:

1.3.6.1.4.1.3375.2.1.1.2.1.74.0 - F5-BIGIP-SYSTEM-MIB|sys global stat|sys stat client bytes in1m "The average number of bytes received by the system from client-side in the last one minute."

1.3.6.1.4.1.3375.2.1.1.2.1.76.0 - F5-BIGIP-SYSTEM-MIB|sys global stat|sys stat client bytes out1m "The average number of bytes sent to client-side from the system in the last one minute."

1.3.6.1.4.1.3375.2.1.1.2.1.81.0 - F5-BIGIP-SYSTEM-MIB|sys global stat|sys stat server bytes in1m "The average number of bytes received by the system from server-side in the last one minute."

1.3.6.1.4.1.3375.2.1.1.2.1.83.0 - F5-BIGIP-SYSTEM-MIB|sys global stat|sys stat server bytes out1m "The average number of bytes sent to server-side from the system in the last one minute."

I am doing the following via custom SNMP monitors in PRTG:

SNMP get of: 1.3.6.1.4.1.3375.2.1.1.2.1.74.0 and multiply that value (which is in bytes) by 8 (to give me bits) then divide the resultant value by 1024 which results in "Client Kbps In"

SNMP get of: 1.3.6.1.4.1.3375.2.1.1.2.1.76.0 and multiply that value (which is in bytes) by 8 (to give me bits) then divide the resultant value by 1024 which results in "Client Kbps Out"

SNMP get of: 1.3.6.1.4.1.3375.2.1.1.2.1.81.0 and multiply that value (which is in bytes) by 8 (to give me bits) then divide the resultant value by 1024 which results in "Server Kbps In"

SNMP get of: 1.3.6.1.4.1.3375.2.1.1.2.1.83.0 and multiply that value (which is in bytes) by 8 (to give me bits) then divide the resultant value by 1024 which results in "Server Kbps Out"

Then, I add all 4 of these values together and divide the sum by 1024 to get Mbps.

However, the issue I am seeing is that the "Total Throughput" measurement on the F5 dashboard is significantly lower than my sum calculated in PRTG of the four measurements shown above. For instance, the dashboard is currently showing 95Mbps and my PRTG monitor says 150Mbps.

Article Comments

Hello,

thank you very much for your KB-Post. The problem most likely is that the 'dashboard' does not the exact same calculation as you are doing in PRTG with the Sensor Factory. Another issue could be, that comparisons on single Speed-Values are always tricky, because they are very sensitive to timing. Comparing traffic volumes over at least one hour is a much more solid basis.

best regards.


Mar, 2014 - Permalink

Ok, so are you saying that with "single speed-values" (in my case, bytes for a specific time interval), it is a best practice to use longer time intervals to get the most accurate data?

The only problem with that in my case is that I need a live dashboard... even a 5 minute interval would be an issue because I need to see in real time the bandwidth utilization of this device. 1 hour is out of the question.

Do you have any estimated percentage of deviation between using 5 second and 1 minute intervals for the 4 SNMP sensors in the above example? I am actually doing that now for this device, and the deviation of the average total throughput for the past 2 hours for each sensory factory sensor is between 0 and 1 megabit. I'm around 200meg right now, so that is 0 - .5 % accuracy between using a 5 second or 1 minute SNMP sensors. Using that logic, jumping to 5 minute or 1 hour SNMP sensors wouldn't increase my accuracy by much. Does that make sense? Or am I crazy? :)


Apr, 2014 - Permalink

Sorry, we do not know the device, nor do we know the OIDs and their values or usual behavior. So we cannot estimate anything here.


Apr, 2014 - Permalink