Help me Fine Tune my Shaper?

[gratis.obake]

Greetings to All,

I would like to ask help from fellow pfsense people about how I can do fine tune these settings for my traffic shaper as these are far from perfect. it is now doing fine and I'm a bit happy with it but I would like some suggestions if you see it fit.

Basically, I have some few computers at home which is mainly for gaming [top priority], while I would also love to have a responsive http/browsing sessions as it permits.

what I want/need/have:

• 4.5mbpish download / .8mbpish upload [internet speed]
• gaming [first priority]
• responsive browsing
• games now go to the right queue, though I still need to find ports to certain games of which the game site itself seems not that cooperative :(

here are the queue [both is similar to wan/lan] (bandwidth/sharelink/upperlimit the same also)
qInternet
-qACK  5%
-qDefault  50%
-qGayming  20%
-qDNS  10%
-qICMP  1%

on my qInternet on LAN side, I seem to limit this to 3.xmbps, I see it sometime have a sluggish UI interface to pfsense.
I know that it needs qLink but doing so and if I have youtube vids, it will surely skyrocket latency on the games.

if you need additional info, let me know, I'll update this as needed.

thanks in advance!

[Nullity]

Remember, you can only prioritize something by deprioritizing something.

Games should be allocated fast per-packet delay. Put simply, all your bandwidth (aka, best transmission delay possible). At worst, this will delay other traffic by milliseconds since gaming traffic demands very low link utilization.

Browsing, since it will most likely be saturating your bandwidth when active, is NOT something you want to prioritize.

This is a complicated topic. Use something aside from HFSC unless you enjoy reading dozens of white-papers. Just use PRIQ or FAIRQ and put gaming at highest priority.

Network monitoring (tcpdump/wireshark maybe netflow) is needed to determine what packets are causing cascading delays.

Do not expect miracles. QoS is meant to guarantee service for a few delay-sensitive services. 20ms here, 50ms there, I doubt you would notice such smalk changes with something like HTTP.

[Derelict]

qGayming

lulz

[Harvy66]

Can we see your configuration on your WAN and LAN interfaces?

This kind of stuff

[gratis.obake]

am really sorry :(, almost forgot my post :(

here is my screenshot similar to the one you posted


[Harvy66]

The hierarchy of the queues look fine, although technically you don't need a qInternet on your WAN except in strange cases. Do you have your WAN interface rate limited? I rate limit my LAN interface also, but if you're using HFSC, you should be able to apply an upper limit on qInternet. Do not use RealTime with HFSC if you're not rate limiting the interface, it will mess things up.

[gratis.obake]

I believe so that I have them limited, honestly am confused a bit but please see below what I have for my shaper values.
note: "Real time" values are all blank and both "Upperlimit" and "Link share" are identical and (m1 &d) are all blank also.

–----------------
all HFSC

qinternet
wan = 768Kb
lan = 3891Kb

qACK
wan/lan = 5%

qDefault
wan/lan = 50%

qGayming
wan/lan = 20%

qDNS
wan/lan = 10%

qICMP
wan/lan = 1%

qLink
lan = 994Mb

on the LAN side, if I need to disable my limit for download, I switch the "default queue" from qDefault to qLink to have it to full speed and switch back to qDefault to limit it again if I'm finished.

one reason I have with 'wan' being "limited" is that I have placed qDefault to 50% and qGayming to 20% as there are instances that if I don't limit wan itself and someone uploads something... (i.e. like picture uploads to facebook or something similar), it will saturate/suck up the entire upload line and kills both Browsing and Gaming sessions == bad.

[Harvy66]

I didn't notice your putty screenshot before. The values look correct. The only other thing I can think of is to make sure CoDel is checked for each of your subqueues. Are you having any issues or just asking for someone to look over your setup? The only thing that stands out is DNS has a few packets dropped, you may want to give it a bit more bandwidth. ACK also seems a little low, possibly move some from default to ACK and DNS. Unused bandwidth gets shared anyway. Best to have too much for your important stuff than too little.

edit: You don't need upper limit set on any queues except qInternet. In the case of your WAN, qInternet really isn't needed, so you don't need upperlimit, it's redundant. Be careful about qLink, if you have internet traffic getting in these queue, it'll break the usefulness of your download shaping.

[gratis.obake]

Codel is indeed selected on all sub queue.

my traffic shaping configuration seems fine…, just that I find it still not that optimal.

anyways,

I seem to notice with my current configuration, specially with the LAN side, when I access the pfsense GUI is too sluggish. It seems that inter LAN communication seems to be limited?, is this due to my qInternet and qDefault on LAN limiting it? (qInternet upperlimit is 3891Kb and is the parent queue on LAN then its sub queue is qDefault which is 50%)

[Derelict]

Accessing the GUI generates hardly any traffic. You would have to really have things hosed to have the shaper influence that. I think you're confusing GUI performance with a shaping issue.

[gratis.obake]

Am really sorry sir, here is my explanation on this one.

scenario #1 (pfsense gui gets super slow response)
LAN side:
qinternet = 3891Kb
    qACK = 5%
    qDefault = 50% [set as default queue]
    qGayming = 20%
    qDNS = 10%
    qICMP = 1%
qLink = 994Mb

scenario #2 (pfsense gui very responsive)
LAN side:
qinternet = 3891Kb
    qACK = 5%
    qDefault = 50%
    qGayming = 20%
    qDNS = 10%
    qICMP = 1%
qLink = 994Mb [set as default queue]

for scenario #1, if I put the default queue to qDefault, pfsense gui response is slow
for scenario #2, if I put the default queue to qLink, pfsense gui response is fast

if you can explain this one and have a good solution to this, I would highly appreciate it.

[Derelict]

Your firewall rules should not be placing local, LAN traffic into anything other than qLink.  I have qLink as the default queue.

Since you want to shape traffic only for flows using WAN, you usually set queues using match rules on WAN out.  That way only traffic having something to do with WAN is put through the shaper, leaving local traffic in the default queue, qLink in my case.


[gratis.obake]

am trying to digest this, but honestly still striving to understand.

if you may sir, can you also post your shaper screen?

[Harvy66]

This is my current setup

[Derelict]

My shapers don't matter.  Your problem is getting traffic into the correct queues.  Until you can do that your shaper config doesn't matter.

[gratis.obake]

hello again to all,

as far as I can see from my configuration, it seems that I am limiting my LAN speeds but how can I fix it?

I seem to have seen post on: https://forum.pfsense.org/index.php?topic=99529.0
one of Harvy66 comment was:

Of course you may want to communicate with PFSense without consume your Internet bandwidth, so create a default queue, place it under qInternet, and create a rule that drops all LAN traffic into qLink

what I see missing is the "how to create a rule that drops all LAN traffic into qLink"?
anyone can give floating rule example how to do that?

anyways…, I'll try to read the article pointed to by Nullity: http://www.linksysinfo.org/index.php?threads/qos-tutorial.68795/

thanks in advance for any replies

[KOM]

Harvy, I was trying to duplicate your config to play around with but I keep getting the dreaded the sum of the child bandwidth higher than parent error.  I set my queues exactly as you specified.  Checked it thrice.  Did the math and all my child queues seem to add up to or less than 100% of their parent queue so I'm stumped.  I tried playing around with qACK and setting it to just 20% RT (removing the 20% LS) but no change.  Am I correct in understanding that each queue level must add up to no more than 100%, and each level is distinct from the others?  Here is what I have that is failing:

WAN
–qACK (20% RT)
--qUnclassified (30% LS)
----qDefault (45% LS)
----qUDP (55%/5/45% LS)
--qClassified (50% LS)
----qNormal (45% LS)
----qHigh (55%/5/45% LS)

[Harvy66]

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?

[KOM]

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.

[Harvy66]

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.

[Harvy66]

Here's my current setup in exactness.

[KOM]

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?

[Harvy66]

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.

[gratis.obake]

@Harvy66,
thanks for the inputs.

@all,
can anyone give me an example of a floating rule to pass internet traffic to a certain queue?

[Derelict]

What kind of traffic?

[gratis.obake]

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?

[Derelict]

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.


[gratis.obake]

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 :(

[Harvy66]

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.

[Derelict]

@Harvy66:

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?

[Harvy66]

@Derelict:

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.

[Derelict]

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.

[gratis.obake]

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]