Are there any plans to move traffic shaper from PF to IPFW?
-
Actually I have tested limiters with FQ_CODEL enabled and it works, but I did not notice any big difference, need more tests but have no time.
-
The future isn't set in stone yet, I heard FreeBSD is removing ALTQ from -current soon. It may be gone from 12, or after. Not sure what the replacement might be. Having some form of QoS is essential, but ALTQ isn't going to be it for much longer. We're keeping an eye on options.
-
Just good reading
http://bsdly.blogspot.com.ee/2011/07/anticipating-post-altq-world.html
I will be happy to see "Enable FQ-CoDel" check box on limiters or "FQ-CoDel" selection on shaper type, where CODEL is already present in pfSense. -
I also vote for FQ-CoDel
-
bear in mind freebsd (and also PFsense since thats based on freebsd), has not been following openbsd's PF for a long while, so this doesnt mean ALTQ is going anywhere.
-
bear in mind freebsd (and also PFsense since thats based on freebsd), has not been following openbsd's PF for a long while, so this doesnt mean ALTQ is going anywhere.
It does when FreeBSD says they're considering removing ATLQ.
-
any source for this info? can only find references to openbsd.
If you are right and it does go, it be a shame as ALTQ with HSFC is the best shaper I have ever used for ingress.
-
No public source (yet)
-
any source for this info? can only find references to openbsd.
If you are right and it does go, it be a shame as ALTQ with HSFC is the best shaper I have ever used for ingress.
In fact that it is the best for you it does not mean it could not be better or even already is, may be you do not use it nowadays.
Also the new subsystem that already came to openbsd to replace ALTQ may be even better.
https://pdf.k0nsl.org/C/Computer%20and%20Internet%20Collection/2015%20Computer%20and%20Internet%20Collection%20part%201/No%20Starch%20Press%20The%20Book%20of%20PF,%20A%20No-Nonsense%20Guide%20to%20the%20OpenBSD%20Firewall%203rd%20%282015%29.pdf
page 118, 131
In fact, it's "always HFSC".
I think ALTQ do not disappear immediately from FreeBSD and it will be available for many years, but will not moving forward.
I have seen some reddit user posts about openbsd 5.x pf working faster then freebsd one, even without SMP support, hard to believe anyway :) -
whilst its good that they using HFSC (page 123 of the PDF), it seems to be a significant dumbing down of the flexibility, ALTQ allows much more granular control then what is detailed in that document. But as I said before FreeBSD is now several years behind openbsd with no plans I am aware of to catch up but instead take their own development path, so openbsd should have no bearing on what FreeBSD does. I now await for some kind of announcement based on what Jim has posted, as at some point they would have to inform the FreeBSD userbase of plans.
-
ALTQ allows much more granular control then what is detailed in that document.
I am not some kind of ALTQ magician, so I should just to believe you, but in fact it is useless when you are on >4G network, it just won't work at all.
-
I do confess to not reading the entire document :) but the bit I read indicated there is no a longer a choice of shaper to use, its just HSFC, whilst currently one can choose between PRIQ,FAIRQ, HSFC and more.
-
I do confess to not reading the entire document :) but the bit I read indicated there is no a longer a choice of shaper to use, its just HSFC, whilst currently one can choose between PRIQ,FAIRQ, HSFC and more.
HFSC new and old can do all the same like PRIQ, FAIRQ do, also you called HSFC the best you need, so what the problem? ;D
My dream in the beginning of the topic was not to remove something, but to add new algorithms on IPFW side, anyway it used already for limiters, so why not to move some shaper jobs to it and in future step by step moving from ALTQ to something better. -
@w0w:
I do confess to not reading the entire document :) but the bit I read indicated there is no a longer a choice of shaper to use, its just HSFC, whilst currently one can choose between PRIQ,FAIRQ, HSFC and more.
HFSC new and old can do all the same like PRIQ, FAIRQ do, also you called HSFC the best you need, so what the problem? ;D
My dream in the beginning of the topic was not to remove something, but to add new algorithms on IPFW side, anyway it used already for limiters, so why not to move some shaper jobs to it and in future step by step moving from ALTQ to something better.Not quite true. Fair Queueing has no strict, technical definition. What HFSC defines as "fair" is not the same as what FAIRQ defines as "fair".
-
The true is that it can, but I did not say how well it do the same job ;)
I don't know what really FAIRQ do, but I've seen your post about FAIRQFair Queueing is per-byte fairness
So yes, definitely it is not the same as HFSC if it's true.
-
@w0w:
HFSC new and old can do all the same like PRIQ, FAIRQ do, also you called HSFC the best you need, so what the problem? ;D
My dream in the beginning of the topic was not to remove something, but to add new algorithms on IPFW side, anyway it used already for limiters, so why not to move some shaper jobs to it and in future step by step moving from ALTQ to something better.The problem is I think choice is king, what is best for me may not be best for someone else.
Also for egress I find fairq+codel the best. HSFC only best for ingress.
-
The problem is I think choice is king
[over-quote deleted]It's not a problem.
Giving us on the first steps in additional to exciting ALTQ use IPFW based shaping is better choice then nothing new. At least it giving you choice and ability to use "less knobs" shaper on modern 10G or other hardware, that do not support ALTQ and possibly never will. This is really giving you choice. Today you just can't use pfSense shaper on those 10G networks, even if it's not widespread.
-
of course if we have both I have absolutely no problem with that. :)
-
Those who are not afraid to experiment, welcome to https://forum.pfsense.org/index.php?topic=126637.msg699341#msg699341
Thanks to qubit, everyone now can try playing with FQ_CODEL at least.