[BUG] Traffic Shaper default queues, and priorities
-
Just checked and your right, when using hfsc scheduler, there's no priority…but if you use other shapers, then the priority appear. Is this normal behavior ?
-
Confirmed on embedded also.
-
There is no concept of priority in HFSC scheduling. The GUI should be fixed to reflect that.
http://redmine.pfsense.org/issues/1994Confirmed the default queue issue as well.
http://redmine.pfsense.org/issues/1995 -
If priorities don't exist with HFSC, then how do I prioritize the traffic? Do you prioritize by the curve slopes? If so, how do you achieve this?
-
Oh damn. Hrmm then HFSC might not be what I want then. Seems like it would be more powerful than the other queuing methods, but unless I can figure out how to specify actual priorities, then I might need to use other queue disciplines.
Now I'm getting curious about limiters and PRIQ/CBQ/FairQ.
Is FairQ even fully implemented? From what I've read about it, it would seem that it would be the best of the remaining 3 disciplines. I might have to play with it and find how it functions, especially with various P2P traffic (tor/i2p/bt).
-
@yaw:
If priorities don't exist with HFSC, then how do I prioritize the traffic? Do you prioritize by the curve slopes? If so, how do you achieve this?
Priority does exist with HFSC but it is not a factor except in cases of contention.
eg. You have a configuration where 2 or more queues compete for existing bandwidth at the same time with the same time delay constraints. Lets say qVoip and qACK both need to send 50Kb of data and both have the M1, D, M2 set such that they must both send the same amount of data in the same time. Obviously, you can't send both at the same time if there is insufficient bandwidth. In this instance, the queue with higher priority gets to send it's data out first.
For all intents and purposes, the actual determination would actually be the M1, D and bandwidth allocation that decides who gets to send first.
-
I switched to FairQ on my WAN side, and now I get this (priorities listed, but no data shown). Where does queue status page get its info?
QUEUE BW SCH PRIO PKTS BYTES DROP_P DROP_B QLEN BORROW SUSPEN P/S B/S
qACK 7 0 0
qGames 6 0 0
qOthersHigh 4 0 0
qDefault 3 0 0
qOthersLow 2 0 0
qP2P 0 0
root_rl0 100M hfsc 0 0 0 0 0 0 0 0
qLink 20M hfsc 83869 59962489 0 0 0 17 2920
qInternet 17M hfsc 0 0 0 0 0 0 0
qACK 10M hfsc 4559 336001 0 0 0 0 0
qGames 1750K hfsc 8461 711418 0 0 0 0.4 32
qOthersHigh 875K hfsc 1638 219883 0 0 0 0 0
qDefault 525K hfsc 19328 23691616 0 0 0 0 0
qOthersLow 350K hfsc 814656 480691K 0 0 0 61 41005
qP2P 175K hfsc 684926 78891391 0 0 0 18 2744Also, I noticed that if using fair/pri/cb Q I lose the ability to nest. Is this intentional?
-
Also - It would be really awesome to have each queue type selected to have it's own contextually generated descriptions. I've noticed that all of the fields have HSFC info but no information on the other queue types.
And btw, in case anyone else read my previous post, the end asking about trees. Only HSFC and CBQ support child queues (http://leaf.dragonflybsd.org/cgi/web-man?command=pf.conf§ion=5 scroll down to QUEUEING) Helps if you read documentation, thought it would be nice to have pfSense's documentation got some TLC for the 2.0 traffic shaper.
-
Priority does exist with HFSC but it is not a factor except in cases of contention.
What is the true story with priority and HFSC. The priority option is still listed in the Freebsd pf.conf HSFC man page.
http://www.freebsd.org/cgi/man.cgi?query=pf.conf&sektion=5&apropos=0&manpath=FreeBSD+9-currentThe priority option is not mentioned in the netbsd altq.conf man page.
http://netbsd.gw.com/cgi-bin/man-cgi?altq.conf+5+NetBSD-currentI can find no structure in the altq_hfsc.h file that would indicate that it uses the priority that is passed to it.
http://svnweb.freebsd.org/base/release/8.1.0/sbin/pfctl/missing/altq/altq_hfsc.h?view=markupI can find no code that obviously mentions pri or priority in altq_hsfc.c. Looking at the hfsc_dequeue code, it first looks for real-time classified packets, Then it looks for the class with the minimum VT (virtual time), it doesn't seem to look for any sort of priority.
http://svnweb.freebsd.org/base/release/8.1.0/sys/contrib/altq/altq/altq_hfsc.c?view=markupSo maybe a bug should be filed with Freebsd to remove any mention of priority from their man pages.
Josh -
Its a generic issue with HFSC in all version of BSD since its inception.
pf(4) parser never bailed about it for not sacrifying generic implementation and the same happened in pfSense.
I knew about it and even forgot to put the comment there for HFSC. -
@ermal:
Its a generic issue with HFSC in all version of BSD since its inception.
pf(4) parser never bailed about it for not sacrifying generic implementation and the same happened in pfSense.
I knew about it and even forgot to put the comment there for HFSC.Ermal, I just want to be clear about what you are saying. Are you saying that the generic issue is that priority is mentioned in the man page, and not actually used?
Thanks
Josh -
@ermal:
Its a generic issue with HFSC in all version of BSD since its inception.
pf(4) parser never bailed about it for not sacrifying generic implementation and the same happened in pfSense.
I knew about it and even forgot to put the comment there for HFSC.Ermal, I just want to be clear about what you are saying. Are you saying that the generic issue is that priority is mentioned in the man page, and not actually used?
Thanks
JoshYes. In the sense that you can configure priority on HFSC but it does nothing in HFSC algorithm as a parameter.
-
After messing with it for a while, I think I found another thing that is wonky with HFSC. I'm still trying to figure out how to get HFSC to play the way I want it to….
If you create a parent queue with say, 10Mb, then in the child queues specify bandwidth in the realtime area, it will bomb out. Apparently pf doesn't consider that you're splitting the bandwidth of the parent, but calculates the interface.
So you can't have this:
WAN (10Mb, HFSC)
CompA (40%, HFSC)
Queue1 (60%)
Queue2 (40%)
CompB (40%, HFSC)
Queue3 (60%)
Queue4 (40%)HFSC seems to calculate the above to mean 280% of the interface bandwidth is used even though only 80% is used or even allowed. (why does it hard-limit you to 80% anyway? ugh)
It may work with bandwidth option only, but any realtime settings are applied to the interface, not the parent. PITA!
Anyhow, hopefully others are having a more pleasant time with the shaper :P
-
Its a matter of implementation.
Real time its about it real time. By definition the quantum of real time curve is the same as interface curve that cannot be less and cannot be more.For link share the concept of splitting bandwidth of the parent exists because it makes sense while real time is about real time and no queuing or anything.