Noob guide to Traffic Shaping
-
So, the most likely (only?) culprit is the bandwidth amount allocated to the root.
Well. The culprit may actually be how pfSense interprets the values specified. I configured a bandwidth limit of 1300 Kbit/s as upload limit on my WAN connection. That's the limit I measured by speed testing without traffic shaping in place.
As a result to this configuration my upload speed was reduced to about 130 Kbit/s.
I then changed the upload limit in the traffic shaper to 13000 Kbit/s. Now I get decent upload speeds again.
I may have completely missed something but I guess something is definitely wrong here even if only the labels in the GUI …
-flo-
-
So, the most likely (only?) culprit is the bandwidth amount allocated to the root.
Well. The culprit may actually be how pfSense interprets the values specified. I configured a bandwidth limit of 1300 Kbit/s as upload limit on my WAN connection. That's the limit I measured by speed testing without traffic shaping in place.
As a result to this configuration my upload speed was reduced to about 130 Kbit/s.
I then changed the upload limit in the traffic shaper to 13000 Kbit/s. Now I get decent upload speeds again.
I may have completely missed something but I guess something is definitely wrong here even if only the labels in the GUI …
-flo-
Sometimes the values will not be accurate, but THAT is crazy inaccurate. I am assuming you have made a fundamental config screwup, but who knows. This stuff is rather complex…
I had to read a good bit of networking theory, traffic-engineering, and pfSense before I had any confidence with my traffic-shaping setups.
-
Sometimes the values will not be accurate, but THAT is crazy inaccurate. I am assuming you have made a fundamental config screwup, but who knows. This stuff is rather complex…
I had to read a good bit of networking theory, traffic-engineering, and pfSense before I had any confidence with my traffic-shaping setups.
I fully agree in regard of the fundamental config screwup just because such a simple error as I observed would already have been discovered earlier very probably. (If it is a chance of exactly one in a million to miss this error, this would have to be expected or course. :-))
My setup is however the result of the wizard (with only VoIP prioritization enabled, nothing else) with no further modifications. So at least there is probably quite a chance of other pfSense users in running into the same problems.
Therefore and because the phenomenon I observed fit closely to what the OP described I posted my own observations on the off chance of being helpful.
@razorhazor: Does increasing the configured bandwith limits by an order of magnitude solve your problem?
-flo-
-
Are you actually using kbits/? Did you accidentally select bit/s?
I set my upload to 98Mb/s and I get 95-97 in actual speed tests.
-
Are you actually using kbits/? Did you accidentally select bit/s?
Yes, I checked that a dozen times. If it was Bit/s I would expect a much stricter limitation anyway.
I set my upload to 98Mb/s and I get 95-97 in actual speed tests.
I'm sure it must be working for most people, otherwise the error would be so simple that it would have been found much earlier. As Nullity put it: There must be a "fundamental config screwup" somewhere at my setup.
-flo-
-
So, the most likely (only?) culprit is the bandwidth amount allocated to the root.
Well. The culprit may actually be how pfSense interprets the values specified. I configured a bandwidth limit of 1300 Kbit/s as upload limit on my WAN connection. That's the limit I measured by speed testing without traffic shaping in place.
As a result to this configuration my upload speed was reduced to about 130 Kbit/s.
I then changed the upload limit in the traffic shaper to 13000 Kbit/s. Now I get decent upload speeds again.
I may have completely missed something but I guess something is definitely wrong here even if only the labels in the GUI …
-flo-
Did you have any luck with this problem? I am having the exact same issue with mine. I basically have to set my connection limits to 10x what they actually are. This seems to be working ok, I just find it odd.
-
Did you have any luck with this problem? […]
Not in terms of clarifying what the cause of this phenomenon is. But as there is a workaround I get along with it.
It's good to hear however I'm not the only one experiencing this effect! :)
-flo-
-
Got a screenshot of your interface with the bandwidth limit?
-
A paste of the output of "pfctl -vsq" would be useful, if you are comfortable with SSH.
-
If this helps solving an issue with pfSense that's fine. Stuff below. There may be more urgent problems to solve however. As I said there is an easy workaround for me.
I have attached screenshot of the WAN interface and a result from a speedtest. (Can anyone point me to a description how I can embed the images within the post?)
The bandwidth limit is set to 13000 Kbit/s. If I set this to 1300 Kbit/s the speedtest result drops to about 130 Kbit/s.
Output of pfctl -vsq is given below.
-flo-
[2.2.2-RELEASE][admin@pfSense.localdomain]/root: pfctl -vsq queue qACK on pppoe1 priority 6 priq( red ecn ) [ pkts: 0 bytes: 0 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 ] queue qDefault on pppoe1 priority 3 priq( red ecn default ) [ pkts: 6811987 bytes: 1452271412 dropped pkts: 3 bytes: 668 ] [ qlength: 0/ 50 ] queue qVoIP on pppoe1 priority 7 priq( red ecn ) [ pkts: 967899 bytes: 194522639 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 ] queue qLink on vr0_vlan2 priority 2 qlimit 500 priq( red ecn default ) [ pkts: 216472604 bytes: 293230584389 dropped pkts: 0 bytes: 0 ] [ qlength: 0/500 ] queue qACK on vr0_vlan2 priority 6 priq( red ecn ) [ pkts: 0 bytes: 0 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 ] queue qVoIP on vr0_vlan2 priority 7 priq( red ecn ) [ pkts: 965109 bytes: 206531511 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 ] queue qLink on vr0_vlan3 priority 2 qlimit 500 priq( red ecn default ) [ pkts: 222617 bytes: 181095806 dropped pkts: 0 bytes: 0 ] [ qlength: 0/500 ] queue qACK on vr0_vlan3 priority 6 priq( red ecn ) [ pkts: 0 bytes: 0 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 ] queue qVoIP on vr0_vlan3 priority 7 priq( red ecn ) [ pkts: 0 bytes: 0 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 ] queue qLink on vr0_vlan4 priority 2 qlimit 500 priq( red ecn default ) [ pkts: 0 bytes: 0 dropped pkts: 0 bytes: 0 ] [ qlength: 0/500 ] queue qACK on vr0_vlan4 priority 6 priq( red ecn ) [ pkts: 0 bytes: 0 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 ] queue qVoIP on vr0_vlan4 priority 7 priq( red ecn ) [ pkts: 0 bytes: 0 dropped pkts: 0 bytes: 0 ] [ qlength: 0/ 50 ]
-
Maybe disable ECN?
