Bandwidth test between 2 RB433AH routers locks at 65Mb/s and processor hits 100%. After a while other users experience dropped packets. Even pinging local lan interface at Mikrotik router shows more than 500ms.
Immediately after stoping bandwidth test everything returns to normal.

Mikrotik OS 3.25 . RB433AH has 680MHz processor and gigabit lan interfaces.

I have tested connecting cable and switches separetely and found no limitiations.

Is this a bug or expected behaviour?

If it is expected then how many MHz is needed for reliable 100Mb connection?

Update:

Even torrents from a single computer cause dropped packets.

-------------------------------
/system check-installation
package routing-test is disabled
package ipv6 is disabled
checking routerboard package...
checking wireless package...
checking hotspot package...
checking dhcp package...
checking routing package...
checking ppp package...
checking security package...
checking advanced-tools package...
checking system package...
done
-------------------------------
/system package print
Flags: X - disabled
# NAME VERSION SCHEDULED
0 routeros-mipsbe 3.25
1 system 3.25
2 security 3.25
3 X ipv6 3.25
4 X routing-test 3.25
5 dhcp 3.25
6 wireless 3.25
7 ppp 3.25
8 hotspot 3.25
9 routerboard 3.25
10 routing 3.25
11 advanced-tools 3.25
--------------------------------

I have found this post.

http://forum.mikrotik.com/viewtopic.php?f=3&t=24453

----------------------------------------------------
user wehrhard
I tested RB600 and RB433Ah and a wrap Board with 500 MHz as well. The best performance was with the WARP Board, followed by the RB433Ah and than comes the RB600. Ok, it has a GB port but if I test the 1 GB port with Btest I get not more than 60-70 Mbit in half duplex. So for what do I need a 1 GB Port if it even does not have 100 Mbit? The WRAP Board has 90 MB in half-Duplex and the 433AH has 70 MB and in half and 35 MB in full-Duplex.

user Staff
impossible, please change your testing methods.
----------------------------------------------------

impossible, please change your testing methods and upgrade to a RouterOS version more recent than one year Current version is v4.6

impossible, please change your testing methods

How?

and upgrade to a RouterOS version more recent than one year Current version is v4.6

Ok.

Off topic
Will my backups work on version 3.30 or 4.6 (in case settings are not maintained after upgrade)?

megahertz don't matter, the routerboards have different architectures and can't directly compare.

Show us from where to where did you run the test and at what settings. also, what kind of configuration do you have on the router? Maybe you have many simple queues or firewall rules?

if it's simple user traffic, are you sure they are utilizing all possible bandwidth?

I think normis answered this in a previous post. If you want to perform a fair test, you need three routers on an isolated network.

powerful router --- test router --- powerful router

It takes a lot of horsepower to generate the random data for the test. I think that is why the 100% CPU. It is generating the random data as fast as it can, and trying to perform other network traffic tasks at the same time.

Just out of curiosity, how would you write a program to generate and send random gigabit-speed data with a 680MHz processor?

megahertz don't matter, the routerboards have different architectures and can't directly compare.

if it's simple user traffic, are you sure they are utilizing all possible bandwidth?

Example:
User from network A starts to download large file from file server on network B. Ping http://www.yahoo.com from router A starts to rise above 500ms and then starts to drop packets.
Torrents from one user machine on network A amount to same result.
Bandwidth test from user machine from network A to router A amount to same result.

Show us from where to where did you run the test and at what settings.

Two routers connected with Ethernet cable via switch. Initially I had no Queues or Firewall rules.
Problem manifested at that point and it did get worse with added rules. In a sense that throughput is getting lower (not by much).

Tools-->Bandwidth test
to router B
tcp
both

also, what kind of configuration do you have on the router? Maybe you have many simple queues or firewall rules?

router A
8 Queues
10 Firewall rules
static routes
adsl in full bridge mode, pppoe connection
2 nat masquarade


router B
4 queues
8 Firewall rules
static routes
DHCP server for network B

FWIW, RB433AH has 10/100 interfaces.

But yeah. Btest from router to router will hog all the cpu. RB433 can handle full 100mbit w/o a problem.

I think normis answered this in a previous post. If you want to perform a fair test, you need three routers on an isolated network.

powerful router --- test router --- powerful router

It takes a lot of horsepower to generate the random data for the test. I think that is why the 100% CPU. It is generating the random data as fast as it can, and trying to perform other network traffic tasks at the same time.

Just out of curiosity, how would you write a program to generate and send random gigabit-speed data with a 680MHz processor?

I would not.
What is the point of a test that hogs the CPU on most routerboards (unless it is testing CPU itself)?
Anyway my post is not about testing tool, as I clearly stated problem appeared during normal use.
We should move discussion about bandwidth test to a software section.

First you post:

Immediately after stoping bandwidth test everything returns to normal.

then you post:

Anyway my post is not about testing tool, as I clearly stated problem appeared during normal use.

??? Am I missing something? Where did you "clearly state" that?

ADD: I am an old sci-fi fan. The old movies used a program to keep the "evil computer" busy by having it compute the value of pi exactly. That is what you are doing with the bandwidth test. It is so busy doing what you told it to do, it doesn't have time for anything else.

I use the bandwidth test to check my queue settings (not the full-speed port), so it rarely has to go more than 2M on my tests.

Seems like running the test on udp instead of tcp does not drain the cpu that much