Community discussions

MikroTik App
 
hadarelv
just joined
Topic Author
Posts: 9
Joined: Sat Jan 15, 2022 10:59 am

HTB limit-at not satisfied

Sat Jan 15, 2022 2:37 pm

Good day

First of all, I would like to mention that I have already read the Mikrotik Wiki, multiple configuration examples and read a lot of forum topics about QoS with configurations similar to what I want to achieve.

My setup looks like this:
- Mikrotik wAP (model RBwAPG-5HacT2HnD) with RouterOS 6.45.9 is connected via its single LAN port to a Linux desktop. Mikrotik works in "ap bridge" mode. It is also set to the 2.4GHz B so that I can limit the physically available bandwidth to ~6Mbit/s. All interfaces are bridged.
- A Linux Laptop is connected to the 2.4GHz channel of Mikrotik

I wrote the simplest server-client C program to send ping-like message from client to server and back per TCP connection. What I want to do now is to guarantee at least 2Mbit/s to the connection between my ping-like program, while iperf3 generates as much traffic as it can to saturate the link (read: prioritise my C programms traffic over iperf3).

Desktop acts as client and sends a single „double“ over WiFi to laptop, which then increments the „double“ and sends it back.

I want to achieve the desired „prioritisation“ of my ping-like traffic with help of Queue Trees. In order to do that, I configured the tree in following way:
/queue tree

add max-limit=10M name=Wlan1Parent parent=global priority=1 queue=default

add limit-at=2M max-limit=10M name=wlan1_low_prio packet-mark=iperf parent=Wlan1Parent queue=default

add limit-at=2M max-limit=10M name=Wlan1_high_prio packet-mark=high_prio parent=Wlan1Parent priority=1 queue=default
This in theory must guarantee 2Mbit/s to both iperf and my ping-like traffic and the rest will be distributed according to priorities. In my case the rest should go to iperf, because ping-connection takes something about 150kbit/s.

In order to make the Queue Tree work, I need to mark the packets to allow their classification in the queue:

/ip firewall mangle

add action=set-priority chain=postrouting comment="Translate DSCP to WMM priorities" new-priority=from-dscp-high-3-bits passthrough=yes

add action=mark-packet chain=prerouting comment="mark the bulk-traffic to port 5101" dst-port=5101 fragment=no new-packet-mark=iperf packet-mark="" passthrough=yes priority=0 protocol=tcp src-address=192.168.88.21

add action=mark-packet chain=prerouting comment="mark high prio data destined to port 5150" dst-port=5150 new-packet-mark=high_prio passthrough=no protocol=tcp src-address=192.168.88.21

add action=mark-packet chain=prerouting new-packet-mark=high_prio passthrough=yes protocol=tcp src-address=192.168.88.254 src-port=5150

add action=mark-packet chain=prerouting new-packet-mark=iperf passthrough=yes protocol=tcp src-address=192.168.88.254 src-port=!5150
By inspecting the counters in the Queue Tree tab I can see, that the traffic is marked correctly and is increasing appropriate counters.

But here is the problem (finally):

When I run iperf3 and then start my ping-like client, it does not become the guaranteed 2Mbit/s and gets delayed a lot (RTT is ~500ms). (He does not even get the actually required 150kbit/s)

If I run only ping-like client without iperf traffic I get RTT ~3-6ms.

RTT measurement is implemented on the client side.

Does anyone see an error in my configurateion? What is lacking in my config?

P.S. I am very new to networking, so the obvious stuff for you might not be so obvious for me:)
 
hadarelv
just joined
Topic Author
Posts: 9
Joined: Sat Jan 15, 2022 10:59 am

Re: HTB limit-at not satisfied

Mon Jan 17, 2022 9:25 pm

After some experiments I have found out that if I generate the priority traffic with another iperf3 stream, the limit-at value is achieved successfully.

I wonder, what could cause such behavior, as both my custom ping-like program and iperf3 use TCP. Following link will demonstrate my code. Does anyone have an idea why Mikrotik does not satisfy the limit-at specifically for my program's traffic? Could that be caused by TCPs backoff? If so, why is it not causing drowning of prioritized iperf3 traffic?

Code:
Client - https://pastebin.com/9PMpbfD6
Server -https://pastebin.com/nwRDhHyf
 
hadarelv
just joined
Topic Author
Posts: 9
Joined: Sat Jan 15, 2022 10:59 am

Re: HTB limit-at not satisfied  [SOLVED]

Tue Jan 18, 2022 4:13 pm

Solved.
My read() call in the client was blocking. Hence, the application actually did not generate the initially estimated bandwidth.

Who is online

Users browsing this forum: Amazon [Bot], marcobag84 and 15 guests