all 1-4 port set to advertise “1000M half” and “1000M full”
port 5 set to advertise “10M half” and “10M full” …
idont know QOS speed limit why not work..so i use advertise to 10Mbps
but…when port5 full speed @ 10mbps…port1-4 got huge delay..0-600ms ping to wan..
is that ROS bug or my problem?
What is your native language? It often makes sense to use Google or Microsoft translation from the native language to English and then back again, and if what you originally wrote in native language still makes the same sense after this double translation, the English version is comprehensible too. But some languages may still not be supported good enough.
To the subject, better post your configuration export, my automatic signature here below says how to do that without revealing any sensitive information. I cannot imagine how reducing bandwidth of one interface to 10 Mbit/s should affect the performance on other interfaces, but maybe there is something else in your configuration. If you shut ether5 down or allow it to negotiate 100 or 1000 Mbit/s, does the issue between ether4 and ether1 disappear?
OK, nothing unusual in your configuration. I can only imagine that the switch chip tells the CPU to pause sending until it manages to deliver already received frames regardless the egress port (which may be a bug of RouterOS or a design limitation of the switch chip, I don’t have any information about the switch chip features), and if the input buffer of the switch chip is long enough, those tens of milliseconds of ping delay could be explainable.
In any case, even if it was a software bug (which doesn’t sound likely to me), the only way to resolve it quickly would be to implement the speed limitation using /queue tree or /queue simple, so that the unlimited traffic wouln’t have to wait in a common queue with the one being throttled.
ether5 is a member port of a bridge, so it cannot be a dst, you must use Bridge as dst.
In order to make queues work, you have to disable the action=fasttrack-connection rule in chain=forward of /ip firewall filter. The very essence of fasttracking is that most packets bypass most firewall processing and queues.
Other than that, your firewall is a mess and provides almost no protection, so if your WAN address is a public one, it needs some changes.
To get a reaction from Mikrotik, you must send the problem description along with a supout.rif file to support@mikrotik.com. This is just a peer help forum and Mikrotik staff doesn’t necessarily read every single topic, so they may not notice this one at all. And even if it can be resolved by a software modification, which may not be the case, expect the solution to take rather months than days.
If you need to throttle only a relatively small share of traffic, you can exclude only that traffic from fasttracking by using appropriate firewall rules (prevent only traffic to/from the simple queue’s target from ever reaching the fasttrack rule by placing action=accept rules matching that traffic before (above) the action=fasttrack-connection one).