Are there any plans to move traffic shaper from PF to IPFW?
-
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.
