Packet drop when connecting through Winbox.

Each time we connect to a router through Winbox, we have packet drop during about 100 ms, even if the router is almost not loaded.


This is not tolerable for VoIP trafic.


Would it be possible to lower the Winbox deamon to a smaller priority so that packet routing would be less impacted ?

What do you log and where do you write log files? Are you connecting through IP or MAC adress?

Connected through IP.

Mac connection does not work reliabily. This is because when a packet is lost, there is no retransmission with TCP. This show that some packets are lost on Router OS.

I think that Packet lost exhibit when the Ethernet chip buffer is full. (interupt has not been served by the main processor).


A solution to solve this is to use larger buffers (increasing latency), DMA, faster processors with a real time linux kernel, or CPLD / FPGA circuits to speed up routing.


I don’t log anything more than the default settings.

Router OS and Routerboards are very nice products, but not enough for serious professional use on VoIP provider backbones (except perhaps if you are very careful about not changing router configuration during the day and not using processor hungry tasks like dynamic routing).

I hope this will change in the futur. Mikrotik has all the good basis to make higher end products for small providers at lower price and with better support than some products on the market.

the comment was “they are routers, not file servers”.
http://forum.mikrotik.com/t/10g-compatibility-performance-with-mikrotik/42396/1

i run video equipment, and even without writes to flash the statistics show around 100ppm loss when the traffic flows through MT.
this is considered “good enough” in this forum, so don’t expect anyone to care about it.
andy

It’s true that certainly most Mikrotik users don’t care about small packet losses.

But for more demanding users, professional or not, it can be a problem.


There isn’t a lot to do to avoid this. Using two processors and a dedicated memory bus for each one could solve the problem.

  • one procesor dedicated to routing, with a linux realtime kernel connected to Ethernet devices

  • one processor dedicated to non realtime tasks (disk writes, management, routing deamons, USB, PCI bus…) with a second kernel, running independantly from the first one and not sharing the same memory bus.

  • minimal communications between the two processors, to avoid contexts switching.

Each processor needs to have its own Linux kernel, so that no hungry deamon can destroy the realtime work of the other processor.

This is the opposite of the actual multi core architecture where a single kernel share two processors and the same memory bus, using an automatic task sheduler and exchanging instructions from one processor to the other if needed.

The advantage of this architecture is that if the processor dedicated to alternative tasks is busy or even crashed, then the routing processor can continu to route packets without interuptions.

The second level of this architecture, would be to replace the first routing processor by FPGA circuitry, but this is quite complicated to do because most of the network and low level Linux code need to be ported to HDL code for implementation with logic gates instead of classic serial processing.

Obviously, i think the second solution is a ten years work at least. This has only been done by big names in the routing and level2 switching world. All the code is proprietary to each hardware or chip manufacturer.

The first solution could be a Linux based project, developped by a Mikrotik sized company or by a community of routing enthousiasts.

The telephony world has shown that big and complex projects could become realistic, with Asterisk and FreeSwitch telephony engines.

It would be nice to see this in the routing world, so that a better use of available low cost processors and logic circuits would be done.

I would prefer to see Linux rise to such advanced and modern network processing architecture, instead of trying to compete with Windows on the Desktop GUI field.