Project

General

Profile

Actions

Bug #14933

open

Traffic Graph Widget only displays half of the real UL/DL bandwidth used under certain conditions

Added by Patrik Stahlman 6 months ago. Updated 23 days ago.

Status:
Confirmed
Priority:
Normal
Assignee:
-
Category:
Dashboard
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Default
Affected Version:
Affected Architecture:
All

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

Problem reproduction:
  • 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

traffic-graphs.js.patch (1.38 KB) traffic-graphs.js.patch fix for issue Patrik Stahlman, 10/28/2023 09:42 PM

Related issues

Related to Regression #14078: Traffic graph shows half actual throughput when switching back to the graphConfirmed

Actions
Actions #1

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.

Actions #2

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.

Actions #4

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.

Actions #5

Updated by dylan mendez 2 months ago

I can still reproduce this in 23.09.1

Actions #6

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

Actions #7

Updated by Danilo Zrenjanin 2 months ago

  • Status changed from Feedback to Confirmed
Actions #8

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)
Actions #9

Updated by Jim Pingle 2 months ago

  • Related to Regression #14078: Traffic graph shows half actual throughput when switching back to the graph added
Actions #10

Updated by Danilo Zrenjanin about 1 month ago

I can confirm that the patch works fine on 23.09.1.

Actions #11

Updated by Danilo Zrenjanin about 1 month ago

To apply the patch successfully, the path strip = 0 must be set.

Actions

Also available in: Atom PDF