Simple QoS bandwidth limiting for buffer bloat
-
What would be the quick and dirty steps for a newbie to implement the recommendations here?
I thought I knew what I was doing, but after I set things up, I noticed my buffer bloat was still an issue.
-
What would be the quick and dirty steps for a newbie to implement the recommendations here?
I thought I knew what I was doing, but after I set things up, I noticed my buffer bloat was still an issue.
For me, "quick and dirty" simply wasted my time. I had to learn some fundamentals before things worked as I expected.
By far, my favorite introduction to QoS/traffic-shaping is http://www.linksysinfo.org/index.php?threads/qos-tutorial.68795/
Perhaps Google some codel tutorials if you must be quick & dirty.
-
Well, Google is what landed me here.
I was hoping someone would expand upon this:
- Set your interface scheduler to Codel or FairQ
- Set the interface scheduler to FairQ, then create a child-queue and set that to Codel
-
I'll dare say if you want simple QoS switch to OpenWRT. Although installing it on x86 is not as simple as it should be nor as easy as pfSense is to install.
But their SQM fq_codel works very well requiring nothing but setting proper upload and download values and ticking 'enable'.
-
Well, Google is what landed me here.
I was hoping someone would expand upon this:
- Set your interface scheduler to Codel or FairQ
- Set the interface scheduler to FairQ, then create a child-queue and set that to Codel
There's not much to expand on that. Just go under traffic shaping and do it. Try one, then the other, see which works best.
Without codel I get an A and with I get an A+. Assume we're talking about DSLReports' speedtest.
-
That's what I did. And it didn't make a difference on DSLReport's testing system.
Do you only set this on the WAN interface?
I've been a m0n0wall user for over a decade. I'm not interested in other FW/Routers….
-
WAN (egress) will probably see the most improvement but ingress limiting can also help.
FYI, Linux (OpenWRT) is where you will find many more scheduling algorithms (fq_codel, cake, PIE, QFQ, etc). BSD distributions seem to be busy preparing to drop ALTQ.
-
So your WAN looks something like this, except set to something like 90% of your actual upload bandwidth?
-
Actually, I was thinking download bandwidth (I didn't have a clue which it was, thanks for clarifying). So, I adjusted it to 5Mbps (I have 6) - now it looks exactly like your screen and I still score an F.
-
PFSense only shapes egress, so you need to do the same thing, except for your LAN interface. When you score and F, is the bloat mostly occurring on your download? For many users, it's almost entirely the upload that's bad, but download can also have issues.
-
It's worse on download. Upload seems to be okay, as best I can tell.
I set the WAN and LAN settings to fairq and 5 / 52 respectively. Still got an F.
-
Post the link to one of your speed tests. From the bandwidth values listed, if you are on Cox Preferred which is rated at 50 Down 5 Up without speedboost you aren't setting your bandwidth values low enough. The idea is to make pfSense the bottleneck, it's the only way it can enforce QoS with this scheme.
-
What mcwtim said. Do the same thing on your LAN as you did on your WAN, but continue to set your bandwidth lower until the issue goes away.
-
I'm on TWC's 50/5 package which, normally speedtest.net and Sam Knows report me having 56Mbps down and 5.8Mbps up (we don't have speed boost here - TWC over provisions).
However, the speed tests to DSLReports are terrible. Only coming in at 10 and 15Mbps.
I'll keep tinkering with the numbers.
-
I'd try an alternative method of testing. Start an extended ping google.com -t
Find a site where you can make a large download for an extended period of time that actually will max your download at rated speeds.
Monitor the ping results while the download is happening, if you have little variance you have controlled your bufferbloat, if not adjust the bandwidth values till you see the results.If you can't get rated speeds anywhere but on easily fudged flash based tests, time to complain.
http://arstechnica.com/tech-policy/2015/06/the-fcc-will-now-take-your-net-neutrality-complaints/
-
Thanks. I've already started yelling at TWC and sending them the SK reports. Apparently, it's not just my neck of the city that is a problem. Lots of folks have been having issues. May have something to do with MAXX coming. I don't know.
Thanks for the quick start. I'll tinker.
-
Old Thread, but just wanted to say thanks.
Bufferbloat was rated as F, made the traffic shaping on the LAN & WAN interfaces as suggested and now I'm getting A+
Hopefully that may help with some gaming issues my son has.
Thanks
-
I'm on TWC's 50/5 package which, normally speedtest.net and Sam Knows report me having 56Mbps down and 5.8Mbps up (we don't have speed boost here - TWC over provisions).
However, the speed tests to DSLReports are terrible. Only coming in at 10 and 15Mbps.
I'll keep tinkering with the numbers.
DSLReports has very good speedtest servers ran in the major datacenters around the world and accurately reflects what you will see from your ISP, ignoring on-premise or peering your ISP may be doing.
In your case, TWC probably has special routes set up to make sure the speedtests get lots of bandwidth, but then have very poor general routing that causes your DSLReports speedtests to be slow.
I don't know about SameKnows, but speedtest.net is very unreliable and gives inflated numbers. One case that I've seen is I when monitoring pfSense for my bandwidth, I saw it blip to 50Mb/s for a short bit, but then was around 40Mb/s for 95% of the test, yet SpeedTest.net claimed I got 50Mb/s. Another case pfSense and my Windows bandwidth widget claimed I only got a peak of 38Mb/s, yet SpeedTest.net claimed I got 51Mb/s.
DSLReports does something like the median or 20th percentile.
-
I'd turn QoS off, and run a dslreports test
