Traffic Graphs shows wrong throughout when traffic shaping enabled
-
Using the latest 2.2 build on amd64 (Intel i7).
When I enable traffic shaping with the wizard the traffic graph (and the throughput on the WAN interface as reported by SNMP) is incorrect. It is showing much lower throughput than is actually occurring. I am testing this by remotely downloading a file from a local HTTP server on the DMZ. The traffic graph for the DMZ is correct, but the WAN outbound is showing about 1/3 or so of the actual throughput.
Otherwise the shaping seems to be working OK. We have dual WAN and three LAN (LAN, DMZ, WIFI - which is handled by its own wifi router).
I tried both HFSC and Priority queuing on all interfaces.
Any thoughts? Known issue?
Thanks.
More info:
The throughput of individual hosts/ips shows up correctly on the traffic graph page. It is just the total throughput of the WAN interface that is being displayed incorrectly it is incorrect both on the dedicated traffic graph page, and in the widget version of the traffic graph on the default page (assuming enable the traffic graph widget)
The SNMP output for the WAN interface is also wrong (which is the most annoying part as I have this in my shell's screen hard status line, and reference it constantly.)
The rrd graphs seem to indicate the correct throughput.
The WAN2 interface, and the LAN, DMZ, and WIFI interfaces all display the correct throughput.
No clue it is makes a difference, but the WAN interface is the second interface (if2 via SNMP).
Thanks.
-
This issue is still present in 2.2.5. I upgraded from 2.1.5 a few days ago and immediately noticed this change.
I noticed that only my WAN interface reports incorrect traffic, a little less than 50% the real throughput.
My 3 LANs are all fine.After some experimentation, it seems to be the 'bandwidth' parameter in the WAN traffic shaper which is 'causing' this.
In my setup it is set to 10Mbit/s. If I remove the value and reload the shaper, the traffic graph shoots up to the correct value. (However the shaper is no longer dropping packets).
Since this is the only interface with a bandwidth value set, it is the only one which has its graph affected. As a result, only outbound traffic on the WAN is shown incorrectly. -
Use pfTop instead of the traffic graph. Traffic graph is just a cutesy GUI thing. Do not rely on it (for now).
@TheUbuntuGuy, if you are using HFSC, Bandwidth technically sets link-share's m2, so Bandwidth can be excluded while having the exact same functionality. When I was diving deep into the undocumented uses of HFSC I had some complex configs that would only work if I left out Bandwidth. The configurations were technically correct, but for unknown reasons, the GUI complained under certain circumstances.
So, maybe the Bandwidth param should be the focus of some debugging.
-
Is this still an issue in 2.3?
… using HFSC, Bandwidth technically sets link-share's m2, so Bandwidth can be excluded while having the exact same functionality.
So I can clear the Bandwidth field, check the Link-Share option, and set m2 at the original value for Bandwidth? I thought the Bandwidth field sets the Upperlimit m2?
-
Bandwidth sets linkshare, which is the minimum amount of bandwidth, not maximum.
-
Bandwidth sets linkshare, which is the minimum amount of bandwidth, not maximum.
So for my setup (below), it makes no sense to set Bandwidth + Upperlimit to the same for LAN1 and LAN2?
WAN, HFSC, Bandwidth: 5Mbps
- qInternet, CoDel, Bandwidth: 5Mbps
- qNormal, Default, CoDel, Bandwidth: 10%
- qHigh, CoDel, Bandwidth: 20%
- qLow, CoDel, Bandwidth: 5%LAN1, HFSC, Bandwidth: 900Mbps
- qLink, CoDel, Bandwidth: 895Mbps
- qInternet, CoDel, Bandwidth: 4Mbps, Upperlimit: 4Mbps
- qHigh, CoDel, Bandwidth: 20%
- qNormal, Default, CoDel, Bandwidth: 10%
- qLow, CoDel, Bandwidth: 5%LAN2, HFSC, Bandwidth: 900Mbps
- qLink, CoDel, Bandwidth: 895Mbps
- qInternet, CoDel, Bandwidth: 1Mbps, Upperlimit: 1Mbps
- qHigh, CoDel, Bandwidth: 20%
- qNormal, Default, CoDel, Bandwidth: 10%
- qLow, CoDel, Bandwidth: 5% -
The upperlimit looks correct in your config. Just an fyi, but Codel does not always play well with really low bandwidth like 1Mb/s and it could aggressively drop packets. The reason for this is Codel is time based and a 1500mtu packet can take too long to send at 1Mb/s and trigger Codel's drop path.
-
The upperlimit looks correct in your config. Just an fyi, but Codel does not always play well with really low bandwidth like 1Mb/s and it could aggressively drop packets. The reason for this is Codel is time based and a 1500mtu packet can take too long to send at 1Mb/s and trigger Codel's drop path.
Hmm, yes I remember something about CoDel and low bandwidths. It probably explains why some webpages just seem to 'hang'.
-
Harvy66,
If I remove the parent "Bandwidth" value and put it in the Link-Share m2, I get a configuration error, because all of the child queues use Bandwidth as a % of the parent. So for:LAN1, HFSC, Bandwidth: 900Mbps
- qLink, Bandwidth: 895Mbps
- qInternet, Bandwidth: 4Mbps, Upperlimit: 4Mbps
- qHigh, Bandwidth: 20%
- qNormal, Default, Bandwidth: 10%
- qLow, Bandwidth: 5%If I'm understanding correctly, the throughput graphs are messed up when HFSC uses the Bandwidth value. I need to limit qInternet to 4Mbps to avoid saturation, but I need to specify the minimum service levels for the child queues as well.
Am I doing something wrong? Or is this still a bug with the throughput graphs?
-
The HFSC config really wants bandwidth provided even though link-share is synonymous. What I've done is just make sure they're both the same if I plan on using link-share for its more advanced features, which I don't really recommend messing with.
-
The HFSC config really wants bandwidth provided even though link-share is synonymous. What I've done is just make sure they're both the same if I plan on using link-share for its more advanced features, which I don't really recommend messing with.
Hmmmkay. So it sounds like what I've done is correct for HFSC, but a consequence is the UI graphs are messed up. I'll just rely on pfTop in the shell.
-
I'm seeing the traffic graph issue as well using a PRIQ shaper. Although it became most pronounced (e.g. off by more than 50% - shows ~4 Mbps for an 11+ Mbps flow) only after I disabled all of the scheduler options (e.g. Codel, RED, ECN, etc). I mentioned this issue at https://forum.pfsense.org/index.php?topic=115862.0 but figured I should post it here as well in case the extra data is usefull. WHen Codel or ECN were enabled, the traffic graph was much closer (within 1 Mbps or so) to being correct (if not exactly correct).
Is there an open bug report for this in redmine? If not, should I open one?