I have 50/200Mb LTE/5g connection. I need to shape my uplink without affecting the downlink.
I’m using simple queue and the uplnik is shaped as expected. Problem is, I’ve set all the limits for the downlink (my target) to 900M and still it gets shaped somehow to 100-130Mbps. Tried different sized queues in the advanced tab, no change.
The simple queue is set up in the most trivial way as in the documentation.
Maybe it is better to use a queue tree. Its function is a bit different, but at least it is clear what it does (and it affects outgoing traffic only when applied to an interface).
great idea, set it up & tested while my wife on call, exactly what I needed!
Yes for priority queuing based on e.g. DSCP it works perfectly. Use mangle rules like this:
/ip firewall mangle
add action=set-priority chain=postrouting comment="From dscp high 3 bits" \
new-priority=from-dscp-high-3-bits passthrough=yes
add action=mark-packet chain=postrouting comment="Priority 0" new-packet-mark=\
prio0 passthrough=no priority=0
add action=mark-packet chain=postrouting comment="Priority 1" new-packet-mark=\
prio1 passthrough=no priority=1
add action=mark-packet chain=postrouting comment="Priority 2" new-packet-mark=\
prio2 passthrough=no priority=2
add action=mark-packet chain=postrouting comment="Priority 3" new-packet-mark=\
prio3 passthrough=no priority=3
add action=mark-packet chain=postrouting comment="Priority 4" new-packet-mark=\
prio4 passthrough=no priority=4
add action=mark-packet chain=postrouting comment="Priority 5" new-packet-mark=\
prio5 passthrough=no priority=5
add action=mark-packet chain=postrouting comment="Priority 6" new-packet-mark=\
prio6 passthrough=no priority=6
add action=mark-packet chain=postrouting comment="Priority 7" new-packet-mark=\
prio7 passthrough=no priority=7
and queue tree like this:
/queue tree
add limit-at=49M max-limit=49M name=internet parent=pppoe-internet queue=\
ethernet-default
add limit-at=8M max-limit=48M name=internet-p1 packet-mark=prio7 parent=\
internet priority=1
add limit-at=8M max-limit=48M name=internet-p2 packet-mark=prio6 parent=\
internet priority=2
add limit-at=8M max-limit=48M name=internet-p3 packet-mark=prio5 parent=\
internet priority=3
add limit-at=8M max-limit=48M name=internet-p4 packet-mark=prio4 parent=\
internet priority=4
add limit-at=8M max-limit=48M name=internet-p5 packet-mark=prio3 parent=\
internet priority=5
add limit-at=8M max-limit=48M name=internet-p6 packet-mark=prio0 parent=\
internet priority=6 queue=pcq-download-default
add limit-at=8M max-limit=48M name=internet-p7 packet-mark=prio2 parent=\
internet priority=7 queue=pcq-download-default
add limit-at=8M max-limit=48M name=internet-p8 packet-mark=prio1 parent=\
internet queue=pcq-download-default
and all traffic will be neatly prioritized.
Of course “simple queue” also has the function to evenly divide bandwidth among multiple
competing (non-cooperative) users, but not everyone requires that.
Thanks, I experimented with marking different protocols in the past but never got to stable solution. Maybe I give this solution a try, but even without this my connection works very smoothly, ping is stable under load, everything’s fine.
My current use case will sound bit weird, but I want to shape my traffic before my ISP does it because their shaping seems to lag and causes big volatility with +/- 50% spikes. With my pre-shaping this is smoothed out very nicely.
Ok, as you mentioned making a call I guessed that you try to do VoIP while at the same time causing network traffic.
The splitting of traffic into different priorities based on DSCP (as in the example) will put things like VoIP and ping into a higher priority than normal web traffic, and you have the option of setting DSCP to certain values for even lower priority than normal (DSCP 8 is lowest, 16 is next higher, 0 is default).
For VoIP the device itself normally applies the DSCP value (46) and no marking is required.
Even having a single queue with max-limit below the actual value you get from the ISP plus having a queue type like “wireless-default” (which is “sfq”) can already solve all issues in practice, by giving all users a fair chance before overflowing a buffer.