Bug #14933
closedTraffic Graph widget displays bandwidth usage values which are half the actual usage amount
100%
Description
Problem description:
The Traffic Graphs Widget fails to display the real bandwidth used after the Dashboard browser tab loses and regains visibility. The problem is fairly easily reproducable.
My Traffic Graphs Widget configuration:Refresh interval: 1
Inverse: On
Unit size: bits
Background updates: clear graphs when not visible
Graph smoothing: 0
- configure the widget as above
- start downloading a large file at consistetly high speed (100Mb/s in my case, WAN max speed)
- verify that the Traffic Graphs Widget shows the expected speed
- switch away from the dashboard (in my case to another virtual desktop)
- switch back to the dashboard and note the Traffic Graphs widget is resetting the graph
- the widget should now show half the expected interface speed (50Mb/s in my case)
Bug and fix:
I found the root cause of this problem in /usr/local/www/js/traffic-graphs.js.
The existing code to handle the case where graph smoothing is zero is not imlpemented consistently.
The values for the graph is calculated here: 286 var trafficIn = ( priorIn[interfaceCount].reduce(function(a, b){ return a + b; },0) + currentIn)/(1 + priorIn[interfaceCount].length);
287 var trafficOut = ( priorOut[interfaceCount].reduce(function(a, b){ return a + b; },0) + currentOut) /(1 + priorOut[interfaceCount].length);
When the graph is correct, variables priorX[interfaceCount].length
is zero as would be expected when smoothing is not taking place.
When the graph is incorrect, variables priorX[interfaceCount].length
is one. This is what is causing the halving of the indicated speed as the division is by 2.
This is the piece of code that incorrectly adds an entry to the list even though no smoothing is active: 288 // circular array to keep track of 'x' amount of data points
289 priorIn[interfaceCount][smoothCount] = currentIn;
290 priorOut[interfaceCount][smoothCount] = currentOut;
With smoothing = 0 this piece of code also has unexpected side effects, smoothCount = NaN after % with zero 340 // increment the circular array
341 smoothCount ++;
342 smoothCount = smoothCount % smoothing;
The attached patch fixes these issues by wrapping the code in "if(smoothing > 0) {}" blocks
This issue was found in Plus 23.05.1 but I expect it is present in all versions of pfSense.
Files
Related issues
Updated by dylan mendez about 1 year ago
I can reproduce this in version 23.09
Reloading the dashboard, starting a 220Mbps download, shows fine. Opening another google chrome tab, then coming back to the graph, it starts over, but speed is 110Mbps.
Updated by Danilo Zrenjanin 11 months ago
- Status changed from New to Feedback
I can not reproduce this behavior on 23.09.1.
Google Chrome for MacOS.
The download speed in the widget remains the same whether I check it initially or after visiting another tab and returning to the original one.
If someone else can confirm that it works fine on version 23.09.1, I will mark this ticket as resolved.
Updated by Danilo Zrenjanin 11 months ago
Related to https://redmine.pfsense.org/issues/14078
Updated by Patrik Stahlman 11 months ago
This problem is still reproducable for me on pfSense Plus 23.09.1-RELEASE. It might not happen every time you switch as there is a race condition involved in triggering the failure scenario.
You also need to have the specific configuration as I describe above, Graph smoothing: 0
and Background updates: clear graphs when not visible
being the important ones.
edit:
In addition to having the right configuration, when trying to reproduce this it is also important to verify that the graph is actually reset after the switch-back. I have noticed that sometimes the graph is updated in the background even though the configuration states that it should not be. The bug is only triggered when the graph is reset on switch-back.
Updated by Danilo Zrenjanin 10 months ago
I was able to replicate the issue using Safari on macOS.
Tests conducted against:
23.09.1
Please submit a pull request following the instructions described at the link below:
https://docs.netgate.com/pfsense/en/latest/development/pull-request.html#submitting-a-pull-request-via-github
Updated by Danilo Zrenjanin 10 months ago
- Status changed from Feedback to Confirmed
Updated by Jim Pingle 10 months ago
- Project changed from pfSense Plus to pfSense
- Category changed from Dashboard to Dashboard
- Affected Plus Version deleted (
23.05.1)
Updated by Jim Pingle 10 months ago
- Related to Regression #14078: Traffic graph shows half actual throughput when switching back to the graph added
Updated by Danilo Zrenjanin 9 months ago
I can confirm that the patch works fine on 23.09.1.
Updated by Danilo Zrenjanin 9 months ago
To apply the patch successfully, the path strip = 0 must be set.
Updated by Steve Wheeler 9 months ago
Updated by Danilo Zrenjanin 7 months ago
Steve Wheeler wrote in #note-12:
I tested the patch against the:
24.03-RELEASE (amd64) built on Wed Apr 24 17:38:00 UTC 2024 FreeBSD 15.0-CURRENT
It fixes the issue.
It can be applied.
Updated by Marcos M 3 months ago
- Subject changed from Traffic Graph Widget only displays half of the real UL/DL bandwidth used under certain conditions to Traffic Graph widget displays half the real bandwidth used
- Status changed from Confirmed to Waiting on Merge
- Target version set to 2.8.0
- Plus Target Version set to 24.08
Updated by Marcos M 3 months ago
- Status changed from Waiting on Merge to Feedback
- % Done changed from 0 to 100
Applied in changeset 3ebe5bc73331be9ca9aa9867867257e0942aca6d.
Updated by Jim Pingle 3 months ago
- Subject changed from Traffic Graph widget displays half the real bandwidth used to Traffic Graph widget displays bandwidth usage values which are half the actual usage amount
Updated by Jim Pingle 2 months ago
- Plus Target Version changed from 24.08 to 24.11
Updated by Georgiy Tyutyunnik 2 months ago
- Status changed from Feedback to Resolved
fix works in
24.11-ALPHA (amd64)
built on Fri Oct 18 8:00:00 CEST 2024
FreeBSD 15.0-CURRENT