Bufferbloat fix with FAIRQ?
-
I'm on the Comcast Extreme 150 tier, which is 150/20. I'm trying to fix the bufferbloat issue by using the speedtest page at dslreports. When I sent the local/internal interfaces to Codelq, I can pass with great results. (Un)fortunately, I have multiple internal vlan's for my workstations, servers, wireless, and visitor networks.
As you can probably guess, when I use codelq, the up speed between vlans is 150Mbit/s, which is what I had set Codelq to use. This gives great results on dslreports speedtests, but the internal network suffers. If I set the scheduler to FairQ, I can then setup different queues up and assign the ports to the queues. I can see under status that the speedtest traffic is indeed getting dumped into the right queue but the bufferbloat on the speedtest page fails.
Is there something that I can do in order to pass the buferbloat tests but yet keep the internal vlan speed at gigabit?
-
OK, after a bit of playing around with things, I think I might of figured it out….but any feedback on if I'm doing this right or wrong is appreciated!!
- Set WAN interface for CodelQ at 20Mbit/s
- Set local interfaces (Servers, Wireless, etc) to CBQ at 1Gbit/s.
- Create two queues under the interfaces, LAN and web
LAN Queue
- Priority: 7
- Default Queue checked
- Codel Active checked
- 850Mbit/s
Web Queue
- Priority: 6
- Codel Active checked
- 150Mbit/s
Then in the firewall rules, choose nothing for the ack and 'web' for the queue. This queue has ports 80,443, and other ports associated with web traffic.
Saved it and it seems like the tests are passing now with A's and internal lan to lan speed is about 800 to 900MBytes/s.
-
SWEET… i tried yours I too have comcast but i was using hfsc.i switched to yours for testing. i know hfsc likes in kbits . comcast blasts download speed sometimes.. how would you control download under the comcast tree. so we don't spike and fail the bloat?
-
Essentially you need to pretend that you don't have blast available.
-
Hfsc can create an internet queue which you put more queues inside of.
You can apply codel to all of them, then use another queue such as qLink and have that run side by side with qInternet
qLink can run at lan speeds, while qInternet is limited to internet speeds
-
You actually don't want the burst. It's great for short lived streams, but confuses TCP for longer lived ones. It does depend on the smoothness of the burst. My ISP's provisioning does a kind of sliding window where going from idle to full speed can allow up to 1Gb/s bursts through my 150Mb connection. When my computer responds to all of these packets at 1Gb/s, the sender will think I can handle 1Gb/s, and it gets follows with a sudden burst of loss or latency and quickly dropping to 150Mb/s.
It comes down to how abrupt the burst is.
Many of the cable modem style bursts use a kind of token-bucket logic, which actually works in your favor for stabilizing bloat. If you limit pfSense to be below your provisioned rate, you can maintain a bucket of burst tokens, letting your connection handle transient spikes, but offloading the QoS processing to pfSense to decide if that spike even makes it through.
-
I would suggest sch_fairq on wan, with a child queue with codel, over sch_codelq on wan
-
"800 to 900MBytes/s."
800MBytes per sec – that is a neat trick ;) hehehe I got to try this queue stuff.. Guessing you meant Mbits/s..
