I understand where the 3% comes from as well. It’s an effort to keep buffers from queuing.
What I am getting at is, in the thread I link to later about the Intel J3160 cpu, Arne determined that with certain CPUs, Cake can bottleneck QoS set to higher link speeds. Also, I did some extensive testing showing how this bottlenecking can look with the J3160. What this means is, with some cpus and higher link speeds, QoS speed settings may have to be set higher in order to obtain lower speeds. If you look at the chart I link to above(the link “I did some extensive testing”), it will become more clear. Also, if you look at my results at the bottom of my opening post, you will see that I am setting QoS speeds to 300Mbps but only getting a maximum of ~275Mbps. When I disable QoS, speeds increase to ~300Mbps. This is where my term “overclocking” comes to play.
In this case, I am explaining about something IPFire’s QoS does in the file at /var/ipfire/qos/settings. When you set your bandwidth at the top of the QoS page (in my case it was 350000/30000), IPFire reduces these numbers by 10% in the settings file. See the lines
DEF_INC_SPD=
DEF_OUT_SPD=
in my original post above. I believe this is a more stringent interpretation of the 3% reduction we discussed above, that is already happening in IPFire’s QoS. My “overclocking” comment here is basically to set your ISP’s speeds to 10% higher in the UI so that after IPFire reduces those values by 10%, you will still have room to maximize your speeds in each individual Class without automatically losing 10%.
I have found that you can set your ISP speeds at the top of the QoS page to 100 times higher than actual and it won’t matter, as long as each Class’s maximum bandwidth does not exceed your network buffers. I believe the purpose of the ISP speeds at the top of the page is for setting accurate automatic settings when you click the Preset button after setting ISP speeds. If you know what you are doing and are customizing each Class anyway, this won’t matter.
In my experience of using IPFire’s QoS for 10 years, a correctly configured QoS will maintain low latency even during high network congestion. That is part of its purpose, and it can be seen clearly on the gateway graph. If you run IPFire for a week without QoS, the gateway graph will have numerous spikes during high activity times. Turn on a correctly configured QoS and after a week, the graph will look much smoother with almost no spikes. This is because IPFire is not allowing data transmission to ever exceed any system buffers.
See my explanation above to your first question.
Cheers!