Tag Archives: queue

Mikrotik Script: Alert on queue tree limit exceeded

scripts, , , , ,

Hi guys,

This is my first post here, I’m a Network Engineer who works a lot with Mikrotik devices and Server Administration and you can see more of my posts on my website. I found this blog some time ago and was invited to contribute with some of my own scripts that may help others!

Today i’ll show you a little script for RouterOS to check if queue tree exceed the limit you set.

For. Example I’ve got a queue tree that limits the amount of total traffic (Upload+Download) to 50Mbps.

I want to know whenever this queue exceed the limit, and I want the system to send me an email.

This is the script:

1
2
3
4
5
6
7
8
9
10
:global checkrate [/queue tree get total-traffic rate]
:local limit 50000000
 
:if ( $checkrate < $limit ) do={
:log info ("Queue not Exceeded")
}
:if ( $checkrate > $limit ) do={
:log info ("Queue Exceeded")
/tool e-mail send server=xxx.xxx.xxx.xxx from="me@myself.com" to="me@myself.com" subject=("Queue Limit Exceed") body=("Queue Limit Exceed, Limit is: " . $checkrate)
}


Enjoy!

Queue outside please!

hardware, software, , , , , , , , , , , , , , ,

New toys you say?

More gadgets Q?

 

Noticed this little gem in the MikroTik wiki this morning while reviewing Queue Types.

Note: Starting from v5.8 there is new kind none and new default queue only-hardware-queue. All RouterBOARDS will have this new queue type set as default interface queue

only-hardware-queue leaves interface with only hw transmit descriptor ring buffer which acts as a queue in itself. Usually at least 100 packets can be queued for transmit in transmit descriptor ring buffer. Transmit descriptor ring buffer size and the amount of packets that can be queued in it varies for different types of ethernet MACs.

Having no software queue is especially beneficial on SMP systems because it removes the requirement to synchronize access to it from different cpus/cores which is expensive.

multi-queue-ethernet-default can be beneficial on SMP systems with ethernet interfaces that have support for multiple transmit queues and have a linux driver support for multiple transmit queues. By having one software queue for each hardware queue there might be less time spent for synchronizing access to them.

Note: having possibility to set only-hardware-queue requires support in ethernet driver so it is available only for some ethernet interfaces mostly found on RBs.

Note: improvement from only-hardware-queue and multi-queue-ethernet-default is present only when there is no “/queue tree” entry with paticular interface as a parent.

What does this mean in laymans terms?

1. The only-hardware-queue will be available initially only for Routerboard devices and perhaps some other supported ethernet chipsets in the future.

2. The basic interface queueing is removed from being passed to the CPU and done on the interface hardware directly which should result in a net performance increase.

3. For SMP (x86 boxes with multiple CPU cores) machines with high end interfaces (1GB, 10GB) there is a queue type that allows a queue to be broken up across multiple CPU cores to match the multiple TX and RX chains offered on these interfaces.