Tag Archives: 10gig

Routerboard 10Gbps capable hardware coming soon?

This was spotted today in the Mikrotik Wiki’s supported hardware list.

Brand Model Rate Connector/Cable Type Wavelength Tested with Works/Doesn’t
MikroTik RB SFP3401 10/100/1000 RJ45, Cat6 RB2011LS-IN Works. Available in Q3!
MikroTik RB SFP5602D-53 155M~2.63G Bi-Di LC, MM 1550/1310 RB2011LS-IN Works. Available in Q3!
MikroTik RB SFP5602D-35 155M~2.63G Bi-Di LC, MM 1310/1550 RB2011LS-IN Works. Available in Q3!
MikroTik RB SFP3420D 1,25G LC, MM 1310 RB2011LS-IN Works. Available in Q3!
MikroTik RB SFP3903D 10G LC, MM 850 RB2011LS-IN and TBA Works. Available in Q3!

.. wait what?

RB SFP3903D listed as 10G and working in a yet to be announced product (TBA).

Are they  referring to another as yet unannounced model of the CCR or something entirely new? More info here as we find it!

Update: Relevant reading from Tilera – http://www.marketwire.com/press-release/Tileras-TILE-Gx-MikroTiks-RouterOS-Unleash-Worlds-First-36-Core-Cloud-Core-Router-1678838.htm 

This would lead us to believe the SFP in question is a 10Gig SFP+ module intended to work in an as yet unannounced CCR model,  joy to the routing world!

Queue outside please!

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.