I tried to play a little bit with my new hap ac3 and noticed that when doing the bandwidth test to 127.0.0.1 using TCP in both directions it only utilises 85% of the CPUs. All other tests (UDP send, receive, both as well as TCP send, receive) utiles 100%. I am wondering why the router can not utilise 100% of the CPUs when the test is TCP both directions.? What is the bottleneck?
是正常的吗?

P.S.For example, I have noticed that CHR on that scenario (TCP both directions) utilises 100% of the CPU, but my hap ac3 not.

What does profile of CPU usage (execute/tool profile cpu=all) show? Are all CPUs loaded equally? I'd expect come CPU cores to be (almost) idle while others loaded 100%. The reason is that ROS is handling TCP connections by using same CPU core for all packets (reason is keeping packets in-order, IP devices in general don't like packets delivered out-of-order) and that could be an issue on devices with multiple CPU cores. This is many times a limiting factor when testing throughputthroughdevice ... iperf tests with multiple parallel TCP streams helps. Not sure if btest (ROS built-in) has this option?

BTW, what exactly are you trying to assess with this test? CPU capability of this device?

Thank you very much on your fast and very informative answer!!
I have retested and can confirm that all cpu cores are equally utilised arround 85% > /tool profile cpu=all Thank you for the command!

I was trying to assess the CPU capabilities compared to other older MTs that I have and compared to CHR and when I saw this I was confused how is this possible. This made me think that something else (not the CPU) is a limiting factor (bottleneck) that does not allow 100% CPU utilisation in this specific case = TCP, both directions. As I am not an expert I asked here and thank you once more for providing your valuable insight!

I would kindly ask some of you that have hap ac3 to test this and report if this is the same situation with your hap ac3s. This will at least show if my hap ac3 is faulty or this unknown/unclear bottleneck is present in all hap ac3s. Tnx very much in advance!

Try setting the number of connections to 200 instead of the default of 20.

Mikrotik have implemented multithreaded bandwidth test (to an extent), but it needs lots of connections to perform at full capacity.

Thank you.
I tried now with 200 connections but it is almost the same. It is even slightly below the 85%. The CPUs utilisation is arround 83% with TCP both directions. All 4 CPUs are approximately utilised equally.
What could be the limiting factor / bottleneck?

EDIT: while testing with different numbers of connections I have noticed another strange results, at least for me this is strange. I would be very grateful if someone can explain it in general:
Example,TCP testing with only one direction = receive
Test 1:连接数= 2;Rx = 1500 Mbps的;cpu = 87%
Test 2:connection count=4; Rx=1400 Mbps; CPUs=100%
Strange conclusion?
Smaller number of connections =smaller cpu utilasation = but greater bandwidth
Vs
Higher number of connections =higher cpu utilisation = but lower bandwidth

Is here someone with hap ac3 who is willing to share his experience? Is such performance expected or is it something wrong with my device? Thank you in advance!

I have no hAP ac3, so cannot make the experiment.

Multithreading processes is not easy, and this distribution over the 4 CPU's is not known. Sometimes there is some form of serialization of the overall process, what makes the CPU wait.
Your CHR is normally a virtual machine, running on a larger host, that might have faster memory, larger memory caches at the CPU, and might define 100%CPU for the CHR differently.

Well there seems to be another bottleneck than just the pure CPU power in the hAP ac3. This reading might be of some interest to you:https://www.batna24.com/uk/mikrotik-hap ... mance-test
Having access to the datasheets of the IPQ-4019 datasheets at Qualcomm requires registration and company validation. I have no access.

But be aware of the TCP congestion control. It reduces the throughput to avoid congestion. There are different algorithms for congestion-avoidance, and the outcome is different.
https://en.wikipedia.org/wiki/TCP_congestion_control. I don't know what algorithm ROS is using, and how it will impact uni-directional and bi-directional flow.

Finding a study for loopback speed tests and bi-directional loopback speed tests is unlikely.
But at least the concepts of this study could shed a light on what is happening :https://hal.inria.fr/hal-01073421/file/RR-LIG-002.pdf
With asymmetric connection speeds, the impact is clearhttps://community.cisco.com/t5/routing/ ... -p/1301840, but symmetric speed , even loopback can still have reduced throughput to some extend.

Thank you so much on such a knowledgeable answer!
I have learned so much just from one post and probably can easly conclude that there is no problem with my device, its just the way it is. I thik that after such an answer there is no practical need for more digging. Only scientific curiosity remains but that's another story.
Thank you once more for your time and willingness to share your knowledge!!