Bug #14933
openTraffic Graph Widget only displays half of the real UL/DL bandwidth used under certain conditions
0%
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 6 months 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 3 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 3 months ago
Related to https://redmine.pfsense.org/issues/14078
Updated by Patrik Stahlman 3 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 2 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 2 months ago
- Status changed from Feedback to Confirmed
Updated by Jim Pingle 2 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 2 months ago
- Related to Regression #14078: Traffic graph shows half actual throughput when switching back to the graph added
Updated by Danilo Zrenjanin about 1 month ago
I can confirm that the patch works fine on 23.09.1.
Updated by Danilo Zrenjanin about 1 month ago
To apply the patch successfully, the path strip = 0 must be set.