This puzzles me… I have tested each of the lines of script on our office Mikrotik before deploying it to the current Mikrotik with the same version.
The second :if ($monitors>7000000)… line was entered because after monitors was greater than 14 nothing else happened.
Now I have noticed that the log shows the value of monitors every time the scripts run but sometimes skips logging the value of traffic.
I have even forced traffic to be greater then 14 but the rest of the script never runs.
The value of traffic will continue to increment until the value of monitors drops below 700000. Then it goes back to 0.
:global traffic
:global monitors
:local counter
:local numberofqueues
:local in
/interface monitor-traffic Lookout once do={:set monitors $“tx-bits-per-second”}
:if ($monitors>7000000) do={:set traffic ($traffic+1)} else={:set traffic 0}
:if ($monitors>7000000) do={:log info $monitors;:log info $traffic;}
:if ($traffic>14) do={:set counter 1;:set numberofqueues [/queue simple print count];:set numberofqueues {$numberofqueues-1};:while ($counter < $numberofqueues) do={:set in {“*”.[:tostr $counter]}; /queue simple set $in burst-limit=3M/3M; :set counter ($counter + 1);};}
:if ($traffic>14) do={:set traffic 1; /system script run wait5;}
Just to clarify the numberofqueues part is required because the last two queues are defaults that we do not change.
The test system has 4 simple queues, and as you can see there’s no id *1 because earlier queues have been deleted. Additionally, I’m not sure you can create ids by combining strings, the type might not be cast right.
To change the rate limit on all but the two default queues, you could for example assign a comment to those two queues (such as “Default queues”), and filter them out:
I’m not sure why you’re increasing the traffic variable, either. Is this script run every now and then by a scheduler and you only want to change queue bursts if a utilization persists over time?
You may want to investigate “/tool traffic-monitor”. You can use that to put a monitor on an interface that fires a script when bandwidth for certain traffic goes above or falls below a threshold.
Yes but we only run the script when it has been above the threshold for 5 minutes.
My understanding of “/tool traffic-monitor” does not have that ability.
You can still use it to make your script much simpler.
Use the traffic-monitor to fire a script when traffic utilization is above a threshold, that script sets a global variable of “threshold-reached” to “([/system clock get time] + 5m)”. The script that fires when utilization drops under the threshold again sets the global variable to 23:59:59 and adjusts the queues to their normal value (blindly, because changing to the same value doesn’t hurt and it makes the logic simple).
Then you schedule a script to run every minute or so that checks whether or not “[/system clock get time]” is larger than the “threshold-reached” global variable. If yes, utilization has been above the threshold for over 5 minutes and you adjust your queues. If not, do nothing.
I’m not sure I understand the issue with not being able to give two queues the same name - what exact problem does that cause?
Yes. You can’t create two queues with the same name. That’s true for pretty much all objects in a Mikrotik router. You also cannot create two interfaces with the same name. Why do you need to name two queues the same?
when this ran it all my dynamic queues created by DHCP were removed.
Only the static ones were left.
Now I have to wait for every ones routers to reup their leases so they get their queues back.