Without QoS, I get a B and sometimes an A on Waveform Bufferbloat. It took additional tweaking in QoS beyond the defaults to get to the A+. I have a tweak guide in the QoS subforum if you want to learn more.
I’ll look for it. I’m getting an A+ rating on my current OpenWRT system but am now discovering that I’m getting an A rating even while disabling QoS. I used to have an F rating without QoS enabled so am going to try an older router that I have and see if that A grade continues where it wouldn’t have 18 months ago without Cake QoS.
Don’t know, I don’t get a good results with some of these sites and I scrutinize their results compared what I get on the command line. Because distances and non-contigous nature of the internet some sites will always be a different performance speeds.
But here is my results with that with my puny 200MB/20MB connection.
The google one is more accurate for me, and the 8ms jitter is RF leakage on my ISP cable system.
Well, I just unboxed my old Edgerouter Lite router and gave it a try. It has no QoS enabled. I get an A-rating now. 917.8/918.3 +12,+3
https://www.waveform.com/tools/bufferbloat?test-id=b3317cec-1db3-47d1-8473-3d3f8086b0ee
936.54/936.94
So apparently something has changed with this connection or is it because I’m running Linux on my endpoints? There doesn’t appear to be a need for QoS at this point.
I thought conventional wisdom said you only really needed QoS on slower lines and it generally wasn’t necessary on 1000/1000 lines. Obviously this will depend on your use case.
An F-grade on a Bufferbloat test proves that wrong. It becomes less likely because it takes a lot of bandwidth consumption to make it happen but typical file transfers try to take everything available and if you happen to be doing a video conference call or something at the same time, you’ll notice. If however, you’re getting an A rating without QoS then that means issues are unlikely. I’m just wondering why my rating went from F to A on the same line without QoS.
I believe your ISP improved the connection. Either that, or you got that F with older router hardware with insufficient buffers.
You’re right. That is conventional wisdom. But it doesn’t mean that QoS can’t help on a fast line. It just means that due to the high speeds, the help will be less noticeable.
I am curious what IPFire’s QoS could do to those results. I have a pretty simple, quick tutorial I posted here if you’d be willing to test it out:
I believe that this statement is correct, depending on what you actually think QoS is. In a way, there is no technical thing that we call QoS. It is a collection of many different things…
The part that everyone will always want, and which is always enabled in IPFire, is AQM - Active Queue Management. It simply looks at all queued packets that are ready to be sent out on a network interface and will categorise them into different buckets. Packets from these buckets will then be sent in priority of the bucket. That way, a VoIP call will always be sent first and large bulky streams like a large download will be sent afterwards. The bandwidth of that interface stays the same and there are no downsides. Instead you are getting nicer real-time applications.
Then there is the stuff that you can configure in IPFire by setting up multiple classes. Maybe that feature should be called “Traffic Shaping”. Back in the day when we added it, traffic shaping was the easy version, but since IPFire did do more, we went with QoS, because that was right at that point.
Traffic Shaping is only interesting if you have a line that constantly saturated and some applications are entirely starved out of bandwidth. Let’s say you have a 100 Mbps symmetric connection but you have 1000 people behind it. If they are all generating a lot of traffic, then the AQM will try to give each connection a fair share of the bandwidth. But if the total number of connections divides the bandwidth so much that each connection only gets a could have kilobit/s, you won’t be able to have a VoIP call any more.
VoIP calls are a nice example, because they pretty much use constant bandwidth of 64 kbps. Nothing more, nothing less. If that bandwidth is not available, packets will be dropped or arriving late, and your call will be a nightmare. If you have a download, bandwidth can be more flexible, it will just take longer, but it will still be successful in the end.
Traffic shaping can now be used to say: well I know there is not enough bandwidth for everything, but always make sure that VoIP comes first, and I don’t care if downloads will become even slower, because I still want to have my call.
It is basically an allocation of bandwidth when there is permanently not enough bandwidth available.
Most people have now access to a lot of bandwidth and most of the time, the connection is rather idle, or even being used to maybe 10%. You will have spikes if you start download the next song of the playing you are playing or so… Normally, there is no need to go through the process to configure QoS, because AQM is doing the work for you.
Maybe this helps as context 
5 Likes
I actually get worse test results.
You see, QOS in bigger bandwidth systems actually gets in the way because the buffers don’t get to reach the memory threshold to achieve total bandwidth in throughput. Even though by stock Ipfire’s memory buffer allocation for the network stack is only configured for 2-2.5Gb of throughput. But since I have a tiny internet connection (200Mb down/20Mb up), I haven’t spent the time working that out, but that is a dev project I am going to work on collectively with everyone once I get other things situated. But as far as inside network, 10Gb works great in file transferring and streaming stuff off of the nas.
My ISP router/server is a commercial isp router built by supermicro. It has 6 10Gb interfaces built into the board and a 2.5Gb card I use for WAN.
Eventually, I will get another one of these 10Gb servers going. Which is going to be my dev computer in this project, but I picked up a trendNET 10Gb card for the WAN so I can figure out a better network stack configuration so IPfire can run at 10Gb throughput. Which is actually easier said than done because there are 6 parameters that will make or break it and its even harder to do to make it universal for all hardware to act the same way. Because there is a point where you have to balance between throughput vs. latency and it dose not always translate from machine to machine exactly the same.
Did you see my post earlier in this thread where I just upgraded to gigabit fiber and QoS improved an already good connection?
That could be because BSD based OS single threads this connection and QOS helps with its buffer because it gets overloaded. OpenWRT is not the same OS nor the network stack is the same. So things there are going to slightly give you different results on a concurrent executing OS like IPFire.
Since QoS just changes package sizes to smaller values, changing the TX length of the interface does the same thing once finding what size to use to send to the modem.
Oh. I didn’t realize you weren’t using IPFire in this situation.
I’m using IPFire. The original poster was using OpenWRT.
QoS doesn’t really work unless the isp system and the modem supports it.
It never did anything positive on my cable TV internet connection no matter whose router I used and had the same connection for the past 20 years.
I’ve used IPFire on at least 4 different hardware platforms and two different ISPs, and QoS has worked normally on each of them. The key is, to limit the incoming and outgoing bandwidths to at or just below the ISPs speeds. Then buffers don’t have a chance to get overfilled. It is easy to misconfigure, which will make things worse. Especially when dealing with guaranteed limits and the different classes.
You really need to stop getting the wrong end of the stick all of the time. You seem to be chasing after some benchmark results that are not relevant in this conversation and many others on this forum.
QoS is not there to maximise the total bandwidth. It will allocate bandwidth and it is there to control latency.
You never never never want to increase any of the buffers that IPFire is using. You never want to play with the sysctl options that you suggest to other users in other threads. That is not where you optimise this.
If you do not achieve 10 Gbps throughput with your hardware, then the problem is the hardware. There is a reason why we propose using certain hardware and we can generally not guarantee that you are getting best results with anything that you get off of eBay. CPU models matter, but so many more things matter to us and they are usually not part of the spec sheets. You might be looking at either bad PCIe lane usage or simply just some network interfaces that claim to support 10G when they actually don’t. Large buffers might increase throughput (and would confirm my theory), they will however not improve your network.
This is absolutely incorrect. There won’t be any fragmentation.
More incorrect stuff. Please stop posting these things. I don’t want to read them.
4 Likes
Thats nice, however now when I turn on Qos all outside traffic stops which it didn’t used to do that. I haven’t modified anything in that IPFire either. Just went through the guide and entered the numbers calculated from the waveform bench result.
But looking at the network stack, the iptables bandwidth from green to red is about 2.5Gb by my calculations. But that is a different subject all together associated with memory allocation.
Its dosen’t fragment, what I understand is that it dynamically changes packet size, however, there are other mechanisms in the stack that will collapse the packet after so many bytes, but decreasing Tx queuelegnth does the same thing. But since this is not a client I don’t think it would scale properly in this application. Ubuntu sets it at 100 where we have the default from Linux main at 1000. Sysco runs 5000 in their 24 x 10Gb router. OpenWrt and OpnSense is 2500. Eventually I am going to set up a test bed to try different networking stacks from different routers. Because there is no universal settings for this it seems.
I just think you don’t know those kernel parameters do to be honest. Otherwise you wouldn’t have told me the network part of this needs to be redone in the email you sent me.
I know I am annoying and I apologize. 
I think in all likelihood there is a misconfiguration. If you’d like to solve this, create a separate post in the QoS subforum and screenshot your QoS page and ping me in the post. I’d be happy to work through it with you.
1 Like
I would think unconfiguration. As I see I only have a couple of things entered. Too bad it looks like this thing is just flat configuration compared with other routers that all you do is type in the in/out bandwith and hit a check box. But I’ll set up a post so I can see again that Qos doesn’t do anything positive. Why would that change? But let’s see.
Edit
I posted a new thread, lets see if QoS do anything positive or negative to a IPFire server that is configured 10Gb x 6 LAN + 2.5Gb Lan on a 200/20 service that I have twice that with no Qos.