[BUG] Traffic Shaper default queues, and priorities
-
Okay, I've found a bug in the traffic shaper involving modifying the default queue. If you do so, and hit save, the changes are lost, and it complains that there can only be one default queue. Workaround for now is to make changes, remove the default flag, then save, then re-flag the default, and re-save. Annoying, but workable.
There are also a few other bugs, in that sometimes you can create/change a queue, and hit save, and… nothing happens. No error message, or anything. Just errors out and appears to do nothing.Another possible bug is that I'm not sure that it is actually assigning priorities, which may be part of the overall problem with the shaper. I just noticed this today.
pfTop: Up Queue 1-17/17, View: queue, Cache: 10000 09:24:10
QUEUE BW SCH PRIO PKTS BYTES DROP_P DROP_B QLEN BORROW SUSPEN P/S B/S
root_nfe0 100M hfsc 0 0 0 0 0 0 0 0
qInternet 1455K hfsc 0 0 0 0 0 0 0
qACK 873K hfsc 95002 6199288 0 0 0 21 1412
qGames 145K hfsc 2116 457541 0 0 0 0 0
qOthersHigh 72750 hfsc 1051 91006 0 0 0 0 0
qDefault 43650 hfsc 287324 249074K 0 0 4 38 29067
qOthersLow 29100 hfsc 616113 277105K 1970 921688 26 108 36523
qP2P 14550 hfsc 68953 26944758 0 0 0 14 4654
root_rl0 100M hfsc 0 0 0 0 0 0 0 0
qLink 20M hfsc 26048 4702278 0 0 0 4 693
qInternet 17M hfsc 0 0 0 0 0 0 0
qACK 10M hfsc 86124 5558432 0 0 0 16 1088
qGames 1750K hfsc 1885 230691 0 0 0 0 0
qOthersHigh 875K hfsc 592 80994 0 0 0 0 0
qDefault 525K hfsc 157919 123209K 0 0 0 33 25733
qOthersLow 350K hfsc 687961 412926K 0 0 0 129 82548
qP2P 175K hfsc 118213 14330565 0 0 0 26 3774The part that troubles me is that there are only two queues that show priority. The others don't have any priority at all showing up. So, I'm not sure if it is actually prioritizing queues, or if it is just limiting them by the queue definitions, or if this is an ntop glitch.
-
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.