QoS Working As Intended?
-
I think you'd need to share your LAN queues (all of them) to see what the full config is.
If you are saying you are only getting ~50Mb/s download from your usenet.
I tend to make as few queues to meet my requirements and as few rules as possible. Too hard to figure things out if it's complex.
As requested. Thanks for the help.
.png_thumb)
.png)
.png_thumb)
.png)
.png_thumb)
.png)
.png_thumb)
.png)
.png_thumb)
.png)
.png_thumb)
.png)
.png_thumb)
.png) -
According to your settings you should get 4.95% of bandwidth for Usenet (qOtherLow). So may be you get 5Mbps?
Try to leave bandwidth field empty for the queues. Leave only m2 value on "B/W share of a backlogged queue" with link share enabled on all queues, except voip. -
@w0w:
According to your settings you should get 4.95% of bandwidth for Usenet (qOtherLow). So may be you get 5Mbps?
Try to leave bandwidth field empty for the queues. Leave only m2 value on "B/W share of a backlogged queue" with link share enabled on all queues, except voip.Link-share m2 & "Bandwidth" are the same thing behind the scenes. Also, link-share shouldn't put any upper limits on bandwidth so I'm unsure why OP is experiencing slower usenet speeds.
-
@w0w:
According to your settings you should get 4.95% of bandwidth for Usenet (qOtherLow). So may be you get 5Mbps?
Try to leave bandwidth field empty for the queues. Leave only m2 value on "B/W share of a backlogged queue" with link share enabled on all queues, except voip.Link-share m2 & "Bandwidth" are the same thing behind the scenes. Also, link-share shouldn't put any upper limits on bandwidth so I'm unsure why OP is experiencing slower usenet speeds.
Are you sure?
At least you can put different values into those fields, for example if you put 60% into bandwidth and 75% into m2 link share bandwidth field the rule created looks like
queue Everything on igb0 bandwidth 60% qlimit 1000 hfsc ( rio , ecn , default , linkshare 75% )
I am not quite sure is it the same thing in overall, but you are right that this should not put any upper limit on bandwidth if your network not under load, except this Usenet downloading
I can only assume that somebody else eats overall bandwidth… ??? -
@w0w:
@w0w:
According to your settings you should get 4.95% of bandwidth for Usenet (qOtherLow). So may be you get 5Mbps?
Try to leave bandwidth field empty for the queues. Leave only m2 value on "B/W share of a backlogged queue" with link share enabled on all queues, except voip.Link-share m2 & "Bandwidth" are the same thing behind the scenes. Also, link-share shouldn't put any upper limits on bandwidth so I'm unsure why OP is experiencing slower usenet speeds.
Are you sure?
At least you can put different values into those fields, for example if you put 60% into bandwidth and 75% into m2 link share bandwidth field the rule created looks like
queue Everything on igb0 bandwidth 60% qlimit 1000 hfsc ( rio , ecn , default , linkshare 75% )
I am not quite sure is it the same thing in overall, but you are right that this should not put any upper limit on bandwidth if your network not under load, except this Usenet downloading
I can only assume that somebody else eats overall bandwidth… ???I think the "Bandwidth" param is purely a generic ALTQ/pf param that must translate to something that relates to the particular ALTQ queueing algorithm. In HFSC's case, technically there is no "Bandwidth" param. HFSC has only link-share, upper-limit, and real-time, so "bandwidth" has translate into one of those.
I forget which takes precedence, but I assume it would be the explicit link-share param rather than the generic bandwidth param.
-
I'm going to be honest, you guys have mostly lost me… though I appreciate the back and forth my topic has generated.
I can say with 100% certainty that nothing else is using my network when I was monitoring my usenet downloads. So based on my initial question, it appears that QoS in not working as intended.
Any thoughts on how to proceed, or logs I can provide or testing I can do?
~Spritz
-
Might as well turn off ECN. Some upstream routers abuse this flag to try to force their traffic to slow down. Pretty pointless unless you're an ISP, imo.
Maybe try bumping up your qACK percentage. If it's stifling the ACK transmissions, your incoming download will slow down thinking you're saturated.
-
Tried both those things, it made no noticeable difference. However I enabled codel on all the queue's and that boosted me up to about 8.75 MB/s.
~Spritz
EDIT - I did not enable codel on the qACK for either WAN or LAN. I vaguely recall Harvy66 had made that suggestion, but of course I can't find it now.
-
I'd probably try to break it down and start with a much simpler config to make sure you can get it working with adding all that complexity.
You got a ton of queues and rules so it's kinda tough to figure out what's going on without sitting next to it.
Only other thing I was thinking.
What does . your pfTop show in queues when you are doing that full download?
You should see packets moving through all the queues and I'm guessing you'll see one queue and it'll be stuck there.
When I pump a download from my low queue, I can see the other queues ramp up too.
-
I'd probably try to break it down and start with a much simpler config to make sure you can get it working with adding all that complexity.
You got a ton of queues and rules so it's kinda tough to figure out what's going on without sitting next to it.
Only other thing I was thinking.
What does . your pfTop show in queues when you are doing that full download?
You should see packets moving through all the queues and I'm guessing you'll see one queue and it'll be stuck there.
When I pump a download from my low queue, I can see the other queues ramp up too.
Thanks for the reply. Idid try a simpler setup, basically only having VoIP and NNTP, and I saw the same behaviour. Anyways, here is the output from pftop… I'm not really sure what to make of it...
~Spritz
.png)
.png_thumb) -
Trying to do the math, but if you are matching under qInternet and I add up the queues, I get 15+15+~7+~3 for 40 and if you are getting 20M from qLink, that's 60M so overhead, it seems to add to about 50 down.
I always had my queues adding up to the overall bandwidth that I set on the link above as I wasn't sure how that worked.
My queue looked like:
I'm not sure the purpose of having the qLink over qInternet.
Is that to just further segregating the bandwidth?
-
I'm not sure the purpose of having the qLink over qInternet.
Is that to just further segregating the bandwidth?
AFAIK, qLink is important in a multi-LAN (& WAN?) environment where pfSense routes between LAN interfaces. qLink is intended to be for inter-LAN traffic (full link speed), while qInternet is intended for LAN<->WAN traffic.
