Hitting limit too soon
-
I recently upgraded from pfSense 1.2.3 to 2.01. I am now in the process of rebuilding my traffic shaping policies and have run into a few problems that I just can't seem to figure out. The bigest problem is this:
My queues are dropping packets well below their throughput limits, even when the parent (interface) queue is at less than 40% usage.
I have two 270 kb/s UDP packet flows, one moving from my LAN to my WAN and the another from my LAN to OPT1. I also have a 100 kb/s TCP stream moving from the LAN to WAN. WAN and OPT1 are both connected to ADSL modems and subsequently two different ISPs. Both modems have an 890ish kb/s upstream capacity, so I set the upload rate to 806 kb/s.
I initially set up traffic shaping with the single lan, multi wan wizard such that my traffic would go through the default queues. And indeed, the default queues is where the traffic passes. Unfortunately, my traffic was being limited (for both interfaces) to around 160 kb/s with lots of dropping packets. So I raised the queue bandwidth from around 20% to 40%. No change (yes, I reset the firewall state table). Brought it down to 10%, and the limiting did change to around 90 kb/s.
Next I went back to 40% on the queue and slowly raised the parent queue bandwidth. As I did that, the limit started to increase propositionally.
So why does the bandwidth of the queue seem to be capped at 20% for the parent queue?
I also tried PRIQ and got the same result: 160 kb/s limit with 806 kb/s parent queue bandwidth.
What am I missing here?
My head and the wall I am hitting with it thank you.
Ethan…
-
I disabled Explicit Congestion Notification on my queue that was carrying the UDP data, and it fixed it for a few minutes… then packets started to drop again, but not that bad, about 2%.
I guess I need to read up on Explicit Congestion Notification relative to UDP traffic.
Ethan...
-
One more weird observation: After I apply any change at all to any of the traffic shaper queues, I get not packet loss on my UDP stream queue for about a minute, after which a 2% packet drop kicks in. Very strange!
Ethan…