Many thanks Stuart!


On 07/26/2017 11:37 AM, Stuart Henderson wrote:
On 2017-07-25, Kaya Saman <kayasa...@gmail.com> wrote:
My goal is to use a different queue for up/down were I can change the
max bandwidth accordingly.
Queuing is done outbound, your "in" queues actually need to be on the
outbound interfaces. The trick is that "queue foo on em0" and "queue foo
on em1" are separate queues but traffic assignment is done using the
"foo" part. Don't try to split traffic between _in and _out queues.
The queue is stored with the PF state; the PF state covers traffic in
both directions. So you just want "somequeue", not "somequeue_in"
and "somequeue_out", and get rid of the received-on.

I have revised my queueing statements as you suggested and will definitely look further into adjusting them via your input.

I created a list of vlan interfaces called q_if though in one of the
links above Stuart Henderson doesn't advise it but the vlans are bound
to an lacp trunk with a group of physical interfaces....
Generally I prefer simple failover for trunk, then this would be easy
(a separate queue on each physical interface - the interfaces don't need
to interact with each other, only one is used at a time).

If you must have load-balancing you could play with queueing on the trunk
interface rather than the physical ones, though I haven't tried this.

It's not really load-balancing that is needed but rather a solution to allow for extra throughput-bandwidth when needed. I find the trunk does go up to and over 2Gbps at times.


I'm finding that I don't really need much in the way of "downstream"
queueing though. It might be needed in special cases but using mikeb's
shiny new fq-codel code in -current, one single queue definition on the
upstream interface is keeping traffic flowing nicely.

queue hfsq-em1 on em1 flows 1024 bandwidth $BW_ZEN max $BW_ZEN quantum 400 
qlimit 1000 default

Fantastic! I will take a look at flows, quantum and qlimit and try to understand how these options affect the traffic.


(I am also throttling wifi per-user. OpenBSD's queueing isn't geared up
for that - with v4 you can sort-of do it with loads of separate per-IP
queues but it's horribly ugly, and no good at all for v6 - so I'm doing
that in the APs instead.)


Yeah... wifi is one of those connection types that can be a pain to get to function well. I'm going to have to revise my 802.11 setup at some point to go from "Standalone" AP's to a controller based solution for device handover etc...


Best Regards,

Kaya

Reply via email to