I suggest to add before nano command this one, for future people reading your post
cp /var/ipfire/qos/bin/makeqosscripts.pl /var/ipfire/qos/bin/makeqosscripts.pl.bak
in case of error, config could be reverted with
rm /var/ipfire/qos/bin/makeqosscripts.pl
cp /var/ipfire/qos/bin/makeqosscripts.pl.bak /var/ipfire/qos/bin/makeqosscripts.pl
Anyone feel free to improve/edit instructions with simpler/shorter/more proper/more compliant with Ipfire Standards.
@ms @arne_f
Thank you, guys. I was able to test my setup with fq_codel and it definitely is faster. I am getting between 260-270 Mbps on a 300 Mbps line whereas with Cake I was getting around 190 Mbps.
Thanks to @jon for helping me edit the necessary file.
edit: I may get closer to line speed, but itās late enough in the day where others are now using the internet in my house. But the several speed tests I ran were consistently between 260 and 270, so Iām confident fq_codel is working better than Cake at the moment.
On fast lines it may better but on my slow 6mBit line Cake is much better. fq_codel is always araund 10% slower than line speed and Cake nearly reach it.
I have never used QoS on lines faster than 150mBit because it runs better without the most times.
I agree itās not necessary in my home use case (>150Mbps, very few users), but Iāve used it since Iāve been on IPFire (over 10 years) and I like being able to see what types of traffic are being used via the QoS traffic graphs. And maybe Iām a little bit of a control freak. LOL. Now at work, it is very necessary, but my bandwidth there is only 50Mbps with over 50 users, so I just use it both places out of necessity (work) and habit (home).
@Arne,
Why was there a change from fq_codel to cake?
I did see the blog from Feb 2022.
Also, should I (or someone) add a note to the Quality of Service Wiki to state something like:
It is recommended not to use QoS on lines faster than 150mBit because it runs better without the most times.
PS - this is just out of curiosity. Keep in mind I am not a user of QoS.
I would say that with the exception of the QoS limiting bandwidth on higher speed connections with certain hardware, things do NOT run better without QoS on faster connections. We probably need to update the QoS page with regard to potential bandwidth limitations and mention that on fast connections with few users, most of the benefits of QoS will not be realized. Thatās not to say it canāt be useful with fast connections, but that is not the primary use case for it.
Much better quality of the QoS.
Im not so sure. If you have potent hardware it can use cake also with more than 150mBit.
I have done some QoS/Cake benchmarks. First is the routing in one direktion without QoS the second with QoS via Cake. (iperf3 one tcp downstream)
IPFire Prime 650mBit / 160mBit 2xRealtek
IPFire (Red) 670mBit / 190mBit 2xIntel E1000e
IPFire Duo 939mBit / 660mBit 2xRealtek
APU1 650mBit / 180mBit 3xRealtek
APU2 920mBit / 180mBit 3xIntel IGB
Mitac Pluto (Celeron J1900) 939mBit / 320mBit 2xRealtek
Mforum MT4UB1 (AMD A4-9120 APU) 939mBit / 700mBit 2xRealtek
Kodlix GK45 (Celeron J4105) 939mBit / 580mBit 2xRealtek
Dell WYSE (AMD G-T48E) 300mBit / 160mBit 1xRealtek PCIe 1xRealtek USB2
Im not sure if the bandwich hangs on the core count or on the single core performance but the IPFire Duo and also the A4-9120 are only dual cores. This need more testing.
PS: The APU1 is also only a Dualcore so it seems the single core performace which is important for the cake performance. APU1 has 1Ghz Dualcore and the APU2 a 1Ghz quadcore AMD Bobcat.
I am amazed at the differences.
Where is the iperf3 server? Is it local to the test setup? Or external?
Is there a difference if you are running multiple streams?
I am not too much. This is basically the hardware at their limits. Yes, they all have gigabit interfaces and can pump packets through them. But as explained above, looking a little bit more at a packet is very quickly becoming expensive and the hardware simply doesnāt keep up.
I donāt know which processors are in IPFire Prime, IPFire (Red), IPFire Duo, or APU1/2, but of the rest, there is a very strong correlation between single core performance and QoS speed. Not just max gigahertz, but also Passmark single core results. My J3160 is slower than both the J1900 and J4105 in single core (even though it is faster than the J1900 in multicore) and it performs slower than both in your QoS benchmarks. As you suggested, more cores does not seem to matter to QoS as much as single core speeds.
Both are are external on fast machines. (The connection was full routed through the IPFire.)
Yes, we have posted a little bit about that in the past:
https://www.ipfire.org/blog/feature-spotlight-cryptographic-performance-on-low-end-hardware
Cryptography is another thing that usually cannot be run in parallel (or isnāt worth it). So when building a firewall from scratch, there are a thousands things to consider and just going for a large number of (slower) cores isnāt going to get you very far. However those seem to be cheaper to make.
The main reason why we offer appliances at Lightning Wire Labs is that we have picked a great design from our own experience, tested and verified our assumptions and have tuned the distribution massively to run well on those devices.
I am familiar with the blog post. 
I pretty much have read every blog post of yours for the past 10 or so years that Iāve been using IPFire.
When I bought my Protectli firewall hardware, I did lots of research on the cpu options Protectli offered. I decided on the one I did (with the Celeron J3160) because it had the best combination of single-core and multi-core performance for the money. At least @arne_f 's findings have lead to some good information on how Cake and fq_codel perform on different cpus, which lead to me switching back to fq_codel to restore lost performance. Iām grateful for this community which allows such customization.
When shopping, I did give the IPFire mini appliance serious consideration. It was about double the cost of the Protectli, with a slower processor:
https://www.cpubenchmark.net/compare/5050vs2772/AMD-GX-412TC-SOC-vs-Intel-Celeron-J3160
Single-core is 2.4x faster and multi-core is 1.9x faster. I realize there are other factors that the IPFire mini appliance may have advantages in, but without being able to test both side-by-side, I let my wallet decide. Overall, Iāve been happy with my choice.
Michael, Hereās another data point for you and @arne_f . When I bought this Protectli with a Celeron J3160, my preconception was that it could handle QoS, but donāt bother trying IPS, especially enabled on both red and green. This morning, I decided to try the IPS for the first time in over a year that Iāve owned this firewall. Guess what? Enabled with both red and green (QoS disabled), it gets line speed during speed tests. What?? I guess I shouldāve tried it sooner. So with IPS and QoS, I get the max speed of my QoS (set to below line speed). I think this even more points out how much the Cake QoS was holding my line speed back. It had more of an effect than the IPS.
At any rate, Iām now happily running QoS (using fq_codel) and IPS enabled on both red and green with no impact on download speeds. 
Good to hear. I have been writing a lot of crap tho
Arne and I had a phone call the other week and we are not sure what to with these findings, yet. Technically this isnāt a bug. CAKE works as it should. It simply needs more CPU resources, but it works just fine. We need to gather a little bit more data to see what we can improve. I have a couple of ideas, but no time to test those, yet.
Yeah, that makes sense. I was just trying to make the point that the hardware has been chosen and IPFire has been optimised for it. So absolute CPU performance is definitely not very high on that one, but it doesnāt quite need it.
I keep telling you that we are making things fast
IPFire can skip the processing of the IPS entirely if the IPS has decided that it cannot decode a stream. That is true for most (if not all) TLS connections just after the handshake. So IPFire can run the IPS and only send it the packets it is interested in without wasting any extra CPU cycles on the rest.
I just took a look at my IPFire at work in the file makeqosscripts.pl and those lines are different than even the fqcodel config:
print "\ttc class add dev $qossettings{'DEVICE'} parent 1:1 classid 1:$qossettings{'CLASS'} htb rate $qossettings{'RATE'}kbit ceil $qossettings{'CEIL'}kbit prio $qossettings{'PRIO'>
if (($qossettings{'BURST'} ne '') && ($qossettings{'BURST'} ne 0)) {
print "burst $qossettings{'BURST'}k ";
}
if (($qossettings{'CBURST'} ne '') && ($qossettings{'CBURST'} ne 0)) {
print "cburst $qossettings{'CBURST'}k";
}
print "\n";
print "\ttc class add dev $qossettings{'DEVICE'} parent 2:1 classid 2:$qossettings{'CLASS'} htb rate $qossettings{'RATE'}kbit ceil $qossettings{'CEIL'}kbit prio $qossettings{'PRIO'>
if (($qossettings{'BURST'} ne '') && ($qossettings{'BURST'} ne 0)) {
print "burst $qossettings{'BURST'}k ";
}
if (($qossettings{'CBURST'} ne '') && ($qossettings{'CBURST'} ne 0)) {
print "cburst $qossettings{'CBURST'}k";
}
print "\n";
This is an old installation that has been upgraded several times over the past 10 years. It is current at Core-Update 186. Is this an even older configuration thatās been migrated with my backups and restores over the years? My goal was to make sure my work IPFire was set to CAKE because it only uses a 30Mbps connection.
How would I get this file converted so this systemās QoS uses CAKE?
CAKE currently should be the default for, so if you follow what suggested here
the file should be regenerated with CAKE
You can also look here
to understand which feature is used and toggle it differently.
I must not have explained myself properly. I tried to follow those directions.
The two lines that @arne_f says to search and replace, are not found on this particular system. Where they should be instead are the lines I pasted in my previous post.
In a nutshell, I cannot follow Arneās directions because the lines he says to replace are NOT there on this IPFire system.
Those lines are at different line numbers (194 & 365) to the ones @arne_f indicated to edit.
Donāt change those lines.
The lines to be changed are at line numbers 212 & 383.
The simplest thing would be to search for the following string as it is part of the old and new versions and does not get used anywhere else.
So use @jon ^W method to find the two lines starting with
print "\ttc qdisc add dev $qossetting
and see what the end of the line is in your system.
Thanks, Adolf.
I did this and did not get results. I will try again today in case it was user error. Thanks.