Dear Mikrotik team. In mikrotik heX S board, when the router is working, the total percentage of the processor shows 20%, but when I look at the system resource cpu index, it shows that the first processor is loaded by 80% and the rest of the processors are loaded by 15%. The reason for this is that the SFP port does not support the Hardware offload, it loads a separate CPU and it is not part of the switch. Therefore, it will not be possible to use the router if all traffic goes through sfp.

Hello

Please be aware that this is a user forum. If you want to address MikroTik, I would suggest you write support@mikrotik.com

Regards,


Sent from Tapatalk

No surprise.
It's a router, not a switch.
And you can easily predict this behaviour just looking at the block diagram.

Let us other owners of the hEX S know what Mikrotik state to you so we don't have to write Mikrotik separately on this.

Well, it is a fact, that a lot of new devices due to hardware design are not much good for the new way of how bridging in combination with vlans or bonding is impemented. Unfortunately the devices do not scale very will with cores; a fast cpu is more important than numerous cores. Thus the one and only solution will be to seperate switching from routing and bridging by device. This in fact won't let you pick devices from the lower shell anymore. So with a crs326 and the new rb4011 you should be able to accomplish wire speed throughput. A lot of formerly fast devices are eager to be replaced by newer ones - to Mikrotik's pleasure. - just my 50c

the numbers you write do not correspond with the picture

you say one cpu at 80% picture shows 55%

you say other cpu at 15% picture shows 8, 6 and 13%

please show tools profile to see the source of your cpu usage

Hello
Please be aware that this is a user forum. If you want to address MikroTik, I would suggest you write support@mikrotik.com
Regards,
Sent from Tapatalk

thank you. already sent

No surprise.
It's a router, not a switch.
And you can easily predict this behaviour just looking at the block diagram.

Thank you for the answer. It's a good diagram, but I want to know why in the system resources show separately from system resource cpu?

Let us other owners of the hEX S know what Mikrotik state to you so we don't have to write Mikrotik separately on this.

Shure!!

Well, it is a fact, that a lot of new devices due to hardware design are not much good for the new way of how bridging in combination with vlans or bonding is impemented. Unfortunately the devices do not scale very will with cores; a fast cpu is more important than numerous cores. Thus the one and only solution will be to seperate switching from routing and bridging by device. This in fact won't let you pick devices from the lower shell anymore. So with a crs326 and the new rb4011 you should be able to accomplish wire speed throughput. A lot of formerly fast devices are eager to be replaced by newer ones - to Mikrotik's pleasure. - just my 50c

thanks. I will explore the possibility of a new rb4011

the numbers you write do not correspond with the picture
you say one cpu at 80% picture shows 55%
you say other cpu at 15% picture shows 8, 6 and 13%
please show tools profile to see the source of your cpu usage

The values are changed for every second. In screenshot moment it was with that values. It doesent mean that I am lying. Thank you.

Thank you for the answer. It's a good diagram, but I want to know why in the system resources show separately from system resource cpu?

I don't really get, what you mean.

On your screenshot:
In CPU you have the load: 52% + 6% + 8% + 13% = 79% out of 400%
That's 19,75% of the whole CPU
In system resources you have 21% for CPU load.
19,75% and 21% (rounded) are pretty close
Why the numbers are not equal?
You told it yourself: the load is constantly changing, and may be number in system resources is derived from some previous readings, or average for 1-2-5 seconds.

Anyway, you push over 600Mbit through the CPU and it's only around 20%
So if you scale, I guess it will be first bottlenecked not by CPU, but by the 2Gbit aggregated lanes from the CPU to the ports.
And it corresponds quite well to the official test results:

I solved the problem by connecting the sfp cable instead of the SFP port to the Internet port by RG45. In this case, I was able to use all the processor cores for my needs. And to be honest, I'm a bit frustrated with the HEX S board. I do not understand the meaning of 2 cores and four threads, if only one virtual core is using for the SFP port. IT was not possible to create something else?

I don't think there's a specific limitation that there's a dedicated core which takes care of SFP port. Data flow through interface is more or less serial, there are buffers and queues (if there's QoS in play). So I guess the benefit of multi-threaded process dealing with single interface is nowhere as big as the potential trouble is (just imagine all those race conditions between different threads trying to push their bits through "single wire"). So if there's this single process that takes care of SFP port, it can either run on the same core all zhe time or it can jump between cores ... in the later case it would seem that router is not maxed out as all 4 cores/threads would show around 25% load. And in reality keeping a process running on single core can bring a very slight performance gain (which depends on implementation of certain processor functions, such as L1 cache setup - common vs. per core, handling of specific IO lanes by specific CPU core, RAM access, ...).

i think that workload deserves a bigger device

this cpu features symmetric multithreading (2 threads per core) , cpu average usage around 50-60% must be interpreted like 90-100%

can you publish profile screen-shot to see how the load is distributed across features??

What happens if you don't put the SPF into the bridge. I never put the upstream/downstream in the master/slave or these days bridge.

If I look at the CPU usage I could reach 2Gbit/s if the CPU is maxed.