Help me Fine Tune my Shaper?
-
I don't immediately see any issues with that you're showing. Are you sure the error is for the WAN interface and not the LAN interface for some reason?
Otherwise, for S&Gs, just subtract 1% from all of the values. Maybe there is a rounding issue with translating percentages to the bandwidth values?
-
I don't have a LAN queue defined just yet, only WAN. I'll fiddle with the numbers to see if I can get it to work. Thanks for the confirmation.
Ugh, I give up. Now I'm reminded why I stopped frustrating myself with HFSC many months ago. I went and set every queue option to 10% and it's STILL giving me the same damned error. The error is referencing my vmx0 NIC which is WAN.
Weird that when I shell in and run pftop, the Queues view is empty. I remember (vaguely) that there were some places in the shaper GUI that didn't like percentages, and I'm wondering if I've stumbled on that again.
I blew it all away and only created 3 WAN queues and used absolutes instead of %:
WAN (80Mbps)
–qACK (15 Mb RT)
--qUnclassified (30 Mb LS)
----qDefault (15 Mb LS)Same %#$^# thing. I really give up.
-
BTW, make sure you set the bandwidth parameter. It's still required even though "LinkShare" technically overrides whatever is set in bandwidth. Could be realted to that. Anyway, about to post all of my stuff in pics.
-
Here's my current setup in exactness.
-
Thanks, Harvy. It was the Bandwidth parameter that was the problem.
I notice that for some of your queues, you have a Queue limit, and on others you have Codel, and for some you have both or neither. Could you please explain why that is?
-
From what I understand with HFSC, you can't assign states to parent queues, so no point in setting those. The ACK queue should have plenty of bandwidth with 20%, so I assume the queue will never be backlogged. No point in using CoDel, which has more overhead. I just made sure the queue was large enough to hold a potential burst of ACKs, but there should never be any "bufferbloat".
I typically see about a 20:1 Data:ACK. I should really only need about 5%, but I read somewhere in PFSense that 20% is recommend. It doesn't matter to me, HFSC will distribute the unused bandwidth. HFSC honors the ratio of the assigned bandwidth. I could assign 1% to one queue and 2% to another and it will make sure unused bandwidth is distributed in a 1:2 ratio, I have tried this. I could give ACK 80% realtime and still have pretty much the same results.
Personally I don't like Realtime because it always takes from the root queue, but still counts towards the link share. If I had a parent queue with 10% and a child queue with 20% realtime, it could starve the other sibling queues because the 20% would count against the 10% and the parent queue would have 0 bandwidth. The other thing about realtime is using more than the realtime counts against you. Realtime will make sure that your overall bandwidth usage does not exceed you assigned amount. If you don't give enough bandwidth to a queue that has realtime, and that queue consumes all of its realtime and starts to use linkshare, HFSC will reduce the amount of realtime bandwidth allotted until the the queue falls back within the assigned amount.
I'm not sure if this is tracked forever, I don't see how that could happen, but I assume as long as the link is saturated, an improperly provisioned realtime queue could have detrimental results if it did not have enough provisioned, like link share has no issues. I also find that I can still maintain sub 1ms of jitter using linkshare, so I see no use of using realtime. Example. If I assign 0.5% to ICMP and 99.5% to P2P, even when my link is saturated, I still see virtually no jitter.
Realtime seems awkward to me. It complicates the hierarchical nature of HFSC by taking bandwidth from root, while counting towards the parent, and it seems to give me no perceptible benefit for scheduling. I like to think of everything in terms of bandwidth. The only reason I use realtime with ACK is because that's the default and I see no reason why I can't stick with it just for the sake of the default.
My recommendation when dealing with HSFC is to make sure your time sensitive queues have enough minimum bandwidth. If a queue needs 1Mb minimum, then make sure it has at least 1.25Mb provisioned. Over provisioning does not hurt because unused bandwidth gets distributed. Just make sure your important data has a safe minimum.
If you are so pressed for bandwidth that you need to micromanage and need to worry about jitter because bandwidth is so scare, then worry about HFSC's advanced features. Until then, 80/20 rule and worry about minimums.
Another note about realtime
Because it takes from the root, if you're doing qLink and letting the interface be full line rate, that complicates things because of realtime. qInternet Upperlimit is only respected by linkshare. Realtime ignores upperlimit. This means if you have qInternet set to 10Mb/s, but you have a 1Gb interface, even though qACK is under qInternet, qACK will get its 20% from the 1Gb, not the 10Mb. Now you can't use percentages. Of course you can use absolute values, but those are cumbersome. At least real realtime counts against the linkshare of the parent. Ohh yes, a parent cannot have realtime.
-
@Harvy66,
thanks for the inputs.@all,
can anyone give me an example of a floating rule to pass internet traffic to a certain queue? -
What kind of traffic?
-
am sorry, I'll try to elaborate as much as I can.
on the first page, I have posted my shaper screenshot and you'll see also my floating rules on the first post: https://forum.pfsense.org/index.php?topic=97643.msg553775#msg553775
if you are able to see the LAN side, you'll see that it has qDefault (as the default queue) and have qLink (almost unused :()
I know now that my LAN this is wrong, but I would like to make qLink the Dafault queue again for this one.
now, you see my floating rule…, and how can I divert all other web traffic to qDefault? -
qLink is my default queue. It's set at 1000Mb
Anything not matched by any of these goes into qLink.
I don't feel the structure of the my particular queues is significant. What I feel is significant is how to get the traffic into the queues you want.
Note that my main goal is to improve VPN traffic, which is usually RDP, SSH, or VoIP. I just prefer the VPN tunnel. I have made some effor to shape specific traffic inside the tunnel but found it to be mostly a waste of time. If I was to start doing large file transfers over it I would probably revisit that.
![Screen Shot 2015-09-26 at 2.14.50 PM.png](/public/imported_attachments/1/Screen Shot 2015-09-26 at 2.14.50 PM.png)
![Screen Shot 2015-09-26 at 2.14.50 PM.png_thumb](/public/imported_attachments/1/Screen Shot 2015-09-26 at 2.14.50 PM.png_thumb) -
thanks for the inputs sir,
my main concern is that I have set up my game stuff (shaping and rules)
the only reason I have qDefault there is that it is used to limit all others with download connections.when someone do streaming, it seems to still hog the connection.
I'll maybe restart again with and read again some things here and there :(
-
I personally prefer to set my qDefault under qInternet and qLink is explicitly matched. If I forget to match LAN traffic and it goes to qDefault, who cares, it's just slower, but my ping stays just fine. If my default is qLink and I accidentally place Internet traffic in qLink, then all of my traffic shaping is moot. All it takes is one greedy flow to not be shaped and you'll have lag issues.
-
I personally prefer to set my qDefault under qInternet and qLink is explicitly matched. If I forget to match LAN traffic and it goes to qDefault, who cares, it's just slower, but my ping stays just fine. If my default is qLink and I accidentally place Internet traffic in qLink, then all of my traffic shaping is moot. All it takes is one greedy flow to not be shaped and you'll have lag issues.
That's why for basic shaping I don't even worry about download. I don't even set any queues using LAN rules. For shaping of asymmetric circuits it is almost always the upload that kills performance.
That brings up a question I have not tested. If you have a qLink on LAN as the default queue and you put traffic in it and it flows out WAN where there is no qLink queue, is the traffic placed in whatever the default queue is on WAN? In other words if a queue is set and the queue doesn't exist, is it placed in that interface's default queue?
-
That brings up a question I have not tested. If you have a qLink on LAN as the default queue and you put traffic in it and it flows out WAN where there is no qLink queue, is the traffic placed in whatever the default queue is on WAN? In other words if a queue is set and the queue doesn't exist, is it placed in that interface's default queue?
I want to say yes, but now you got me wondering. I'm pretty sure I had this situation in the past, just not with qLink.
-
I would think Yes as well, because the alternatives would be pick a queue at random or bypass the shaper entirely, which I don't think can be done.
ETA: I just tested forcing traffic from my host on LAN to qLink. Used qLink on LAN for download and qBulk on WAN for upload. There is no qLink on WAN.
-
I have read the article pointed to by Nullity: http://www.linksysinfo.org/index.php?threads/qos-tutorial.68795/
according to the above link and what you guys are saying…, it all goes to controlling/shaping up the "upload" queue which will also directly influences the download stuff.
I have researched a bit and the thing I see ATM is squid's "delay pools"..., but I will still have to try it out.
anyone can point me on how to limit/shape all kinds of streaming (and download as 2nd)? as this is the only thing gives problems on games [when my poor 5mbps link is saturated]