Community discussions

MikroTik App
 
sx10
newbie
Topic Author
Posts: 28
Joined: Fri Jan 04, 2013 5:46 am
Location: Portland, OR USA

Interface queue type

Wed Jan 21, 2015 9:04 am

I'm having trouble finding documentation about interface queues, but I found that they can make a shocking difference in performance. So shocking that I almost wrote off a new CRS210 as useless...

So I bought a new CRS210 and configured it as a home router with one ether port taken out of the switch to masquerate nat an internet connection. The internet connection is 150 megabit, but the CRS was only able to forward 50 meg, and the CPU sat at 100% when this limit was reached. I was shocked that the CRS was performing so badly so I checked the forums. I found a suggestion here to change the interface queue type from only-hardware to ethernet-default. I did this and now I am able to get the full 150+ megabit and the cpu is not spiking to 100%. I'm also seeing the same performance boost when I try this on other mips routerboards I has previously written off as too outdated for faster internet connections.

So long story, but I have a few questions:
1. Why aren't ethernet interfaces set to ethernet-default by default??
2. Is there any disadvantage to using ethernet-default, and should it be set on slave ports?

Thanks,
Greg
 
jarda
Forum Guru
Forum Guru
Posts: 7756
Joined: Mon Oct 22, 2012 4:46 pm

Re: Interface queue type

Wed Jan 21, 2015 9:15 am

I don't understand why you believe that a switch should have routing performance like a router. What information / reasons lead you to put a switch into the role of router?
 
sx10
newbie
Topic Author
Posts: 28
Joined: Fri Jan 04, 2013 5:46 am
Location: Portland, OR USA

Re: Interface queue type

Wed Jan 21, 2015 9:31 am

In this situation I'm trying out a CRS because it is primarily a switch and I do need the 8 gigiabit ports on a single switch chip. However I also need routing on one port so I figured it was simpler to just use one device, since it's perfectly capable of that function. I know a CCR may be better suited but it's also much more expensive, and the only routing needed is a simple masquerade.
 
jarda
Forum Guru
Forum Guru
Posts: 7756
Joined: Mon Oct 22, 2012 4:46 pm

Re: Interface queue type

Wed Jan 21, 2015 1:09 pm

The main difference is how the ports are connected to cpu. Switch role mainly should not involve cpu into traffic at all. In swiching scenario the cpu is used just for administration and monitoring purposes. Therefore the switch chip is connected to some not so powerfull cpu by one data line common for all ports. In routing scenario all ports involved in routing are connected by their own dedicated lines to very powerful cpu that handles the traffic according the programmed rules.

Therefore you cannot complain that switch does not have good performance in routing. Be happy that it is able at least somehow to act as full-fetured router but with performance limitations. For the future, think about using real router for routing and let this switch to do what it is designed for: to make wirespeed nonblocking switching.
 
sx10
newbie
Topic Author
Posts: 28
Joined: Fri Jan 04, 2013 5:46 am
Location: Portland, OR USA

Re: Interface queue type

Wed Jan 21, 2015 6:25 pm

I appreciate your input, but this doesn't answer either of my questions. It also doesn't explain why on a device like the 493 with two switch chips I'm seeing faster switching performance with ethernet-default turned on.

I'd really appreciate it if Mikrotik can provide a more detailed explanation on when the ethernet-default should be used over the only-hardware-queue.
 
User avatar
Caci99
Forum Guru
Forum Guru
Posts: 1075
Joined: Wed Feb 21, 2007 2:26 pm
Location: Tirane
Contact:

Re: Interface queue type

Wed Jan 21, 2015 7:33 pm

There is a short explanation at the wiki:
http://wiki.mikrotik.com/wiki/Manual:Queue#Queue_Types
From this page:
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.
 
sx10
newbie
Topic Author
Posts: 28
Joined: Fri Jan 04, 2013 5:46 am
Location: Portland, OR USA

Re: Interface queue type

Wed Jan 21, 2015 9:01 pm

Yes I did read the wiki page. Still no explanation on pros and cons of ethernet-default and why it is so much faster than hardware-only.
 
User avatar
Caci99
Forum Guru
Forum Guru
Posts: 1075
Joined: Wed Feb 21, 2007 2:26 pm
Location: Tirane
Contact:

Re: Interface queue type

Wed Jan 21, 2015 9:50 pm

As I understand it, hardware-queue is beneficial on switch like scenarios. The packets are processed on the hardware (NIC interface). In router situations, packets are inspected in source and destination, hardware queue will require CPU to do that, which in ethernet-default does not need it since ethernet-default is pfifo queue itself (pfifo=packets first in first out).
 
jult
Frequent Visitor
Frequent Visitor
Posts: 52
Joined: Sat Dec 26, 2020 1:16 am

Re: Interface queue type

Mon Sep 13, 2021 12:36 pm

Yes I did read the wiki page. Still no explanation on pros and cons of ethernet-default and why it is so much faster than hardware-only.
I would, 6 years later, still have to agree. mikrotik offers granular control over what queue type (or "Kind" as mikrotik calls it) to use for what connection, but as it stands there's a bunch of pretty strange defaults, and even ethernet-default can be set to either cake or fq_codel or any of the older types. It's not very clear why it's set to what type.
 
volkirik
Member Candidate
Member Candidate
Posts: 208
Joined: Sat Jul 23, 2016 2:03 pm

Re: Interface queue type

Sun Nov 14, 2021 10:19 am

The queue type (kind) is about packet buffering and packet processing mechanism.

IMHO, PCQ (default size) performs best, offering both zero-packet loss and lowest ping/jitter.

//queue type set [find name=default] kind=pcq
/queue interface set [find] queue=default
/queue simple set [find] queue=default/default

enABLE LOOSE TRACKING

enABLE drop-forward-invalid (but limit; in-interface-list=WAN)

YOU WILL HAVE LIGHTING FAST INTERNET ;D
 
PortalNET
Member Candidate
Member Candidate
Posts: 126
Joined: Sun Apr 02, 2017 7:24 pm

Re: Interface queue type

Mon Dec 11, 2023 12:31 am

The queue type (kind) is about packet buffering and packet processing mechanism.

IMHO, PCQ (default size) performs best, offering both zero-packet loss and lowest ping/jitter.

//queue type set [find name=default] kind=pcq
/queue interface set [find] queue=default
/queue simple set [find] queue=default/default

enABLE LOOSE TRACKING

enABLE drop-forward-invalid (but limit; in-interface-list=WAN)

YOU WILL HAVE LIGHTING FAST INTERNET ;D
Hmm i wonder if it will work on a CCR1036 scenário with over 1k pppoe-users.. 8)
 
volkirik
Member Candidate
Member Candidate
Posts: 208
Joined: Sat Jul 23, 2016 2:03 pm

Re: Interface queue type

Tue Dec 12, 2023 6:23 pm

try decreasing PCQ buffers or better fq_codel with lower buffer sizes

you can even set 1 packet buffer with PCQ or any other queue type.

for example set 2-kbytes for MTUs in range of 1000-2000 bytes.

Please do not set buffer sizes lower than your MTU. It may cause problems.

Who is online

Users browsing this forum: Ahrefs [Bot], BinaryTB and 73 guests