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