It seems ROS3 does not perform well at all on the RB100 series boards. CPU loads consistently spike to 100%, and seems to effect performance. Is this something you're (mikrotik) working on and aware of? Or are these boards going to be replaced with RB400 series, with more capable hardware?

I no longer order the RB133c's, replaced with RB411's.. unfortunately theres no replacement for the RB133 yet, unless you go to the RB333 which has a significant price jump.

Is there an answer to the CPU jump, I have an RB150 that jumps to 100% every 5 seconds or so, then back down to 3-4%.

The router, when "busy" pushes all of 128k of traffic.

Thanks,
-Russ

也许是监控的家伙吗?在这种情况下CPUcan increase when muliple services are being polled (like SSH)

I see the spikes with idle equipment sitting on a bench, with no interfaces connected, aside from the ethernet. No services being polled/monitored by dude. Spikes seen in winbox, not sure if they exist when connecting via SSH/telnet. I'll look into that and reply back.

Packages installed:

高级工具
CLEA
DHCP
PPP
Routing
System
Wireless
NTP

ROS V.3.xx (happens on all up to the current release 3.4)

I have heard of issues with the "legacy" NTP package...
Are you running the new package?

I got the same issue on a rb150 runing ROS 3.4, the terminal inside of winbox crash, and the rb must be reseted...
I didn´t use the NTP....

Somewhere on this forum is explained the difference in ros 2.9 and 3.x I don´t know anymore where but what I remember is that it comes down to the cpu monitoring time lapse. In 3.x it is more precise than in 2.9. It monitors in shorter time lapse.
每个cpu都有100%的峰值。实际上,所有的活动ty happens at 100% of the cpu's capacity. If it is only a very small task it only takes such little time the monitor that calculate the usage over some time calculate a low usage. The shorter this monitor's ´time-lapse` is, the higher a cpu load for a certain activity.

What is really important to see is the average usage over a somewhat longer period of time. Let say some minutes or more. The longer the monitor show a higher usage level the heavier the load is. As long as you do not see a consistent (5 mins, 10 mins or longer) higher then 60-70% cpu usage the cpu is fine and just doing what it is made for.
Compare it with your CPU load of your Windows or Linux PC. Go to task manager and see what the CPU of your PC is doing. You will high loads of it when you run a video, calculate big spreadsheets or compress a big file. Both is loads of work and the processor has to ´work´. But simple tasks as opening a simple text file still creates a ´spike´ of almost 100%, but only for a very short time. An even simpler taks would even create a 100% spike but will be so short in time the cpu usage graph doesn´t even show it anymore, or only with 10 or 20% or so.

我认为rb133c´t是要被取代on, they are just on the market for a year or so and they function perfect as client CPU with firewall and mangle rules in place on 3Mb links and with ros3.x and are relative cheap.

I have 50 of these running and general cpu usage shows 10-30% cpu load, with the spikes of 100%

Bottom line, if nothing special went wrong and the rb100 series boards are working normal spikes of 100% are nothing to worry about.

rgds.

Rudy

In the RB150 seems not to be a normal issue, it crash the ROS... I´m not talking about CPU spikes, I´m talking about crash... the config? 1 Bridge, with ether1,ether2,ether3,ether4,ether5.... I used as a switch....
The ROS CRASH !! not just spikes of CPU...


Downgraded to 2.9.51..., the issue dissapear.

What about a replacement for RB133? RB333 is too expensive for some situations.

In the RB150 seems not to be a normal issue, it crash the ROS... I´m not talking about CPU spikes, I´m talking about crash... the config? 1 Bridge, with ether1,ether2,ether3,ether4,ether5.... I used as a switch....
The ROS CRASH !! not just spikes of CPU...


Downgraded to 2.9.51..., the issue dissapear.

Regarding upgrade from 2.9.x family to 3.x some issues are shown on this forum. Some of these should be cleared in 3.4 according the change log. Read this forum. There are several treads about cards crashing after the upgrade and in some cases solutions are given, some cases also see the cards being returned to the supplier/MT.
Also, what do you mean with a ´crash´? There are several different problems that can happen people refer to as a ´crash´ and so there are several solutions (or none if not) related to the type of crash.

But the crashes are still a small minority. And they happen on almost any type of boards. Lots of boards have been upgraded under the same circumstances as the failing ones. Some crashed, most not.

rgds

Rudy

If the winbox program is crashing try removing all of the mikrotik related files in %userprofile%\Application Data\ folder.. delete winbox.exe and redownload from your router.. ROS 3.xx uses a newer version of winbox.

If the router itself is crashing, i'd reinstall ROS via netinstall.

WirelessRudy -- I have a device sitting idle doing nothing. There should be no reason why it consistently spikes to 100% load every few seconds.

Literally has no configuration, did a Netinstall and logged in. I'll do some further testing today and reply back. I want to know if this is effecting performance as well.

WirelessRudy -- I have a device sitting idle doing nothing. There should be no reason why it consistently spikes to 100% load every few seconds.

Literally has no configuration, did a Netinstall and logged in. I'll do some further testing today and reply back. I want to know if this is effecting performance as well.

William,
How do you see the CPU ´spikes´? This is some CPU routine just doing this.... so here is your little activity!
And just the way you monitor your routerboard is already creating some activity from the CPU as well. Here´s another source..... If the CPU would really rate 0% for a long time I would consider it to be dead! (How can you monitor a CPU that is dead? By showing some ´spikes´ it at least tells you its healthy!

And believe me, when the 100% spikes only happen irregular and occasionally, some high spikes every two or three, four minustes, it is very normal. My P5 with 1Mb internal is always showing some 100% spikes, even if there is really no traffic so he really has nothing to do then showing me that he is ´alive´.

rgds.

Rudy

Hello,
unfortunately I have the same problem, CPEs based on RB133c easly jump to 100% CPU usage.
Using the device directly connected to the PC for configuration settings (no snmp, no ping, no traffic on interfaces), it simply crashes when I try to do en export command. E.G. "[CPE_RB133c]>exprt file=test", results in a crash: CPU usage stops at 100% and (after 10-20sec.) WinBox disconnects.
If same command is executed in Telnet mode (with no WinBox active), problem doesn't accour. This is evidence that CPU resources are not enough, hope that new RB411 gives better results...

This is a great problem because, working on CPEs already installed at Customer's site, 100% CPU usage means disconnection from wireless network...

Rgds

cpresto,
It sounds to me you have another problem.
I have 10 rb112 CPE's and 57 rb113c's CPE all running now versions 3,0 or 3,2 or 3,4 in a production environment. None of these is crashing and none of these see long time spans (in secs) of high CPU usage. They all have firewall filters running and traffic over them runs as 3Mb max. and even then low CPU usage. I don´t see what is wrong with these recent desiged boards (rb133). They perform fine.
I really think you have a problem of a different kind, suggest you send a mail to support or ask on this forum if anyone can help you.

rgds.

Rudy

This is stupid bug.
All day RB411 has cpu on 100%. Why ? Because its monitored by Dude.
I disabled all services but ping and rb is running smoothly now.
Some of RB133 have similar problem i have 2 of them.
you can configure it after reinstall but after very quick time they are unusable!
symptoms are like described above (100% cpu, winbox-terminal crashes).
i dont know does rb were monitored by dude when these problems ocured.
worth trying.

Hello,
as described in my post, RB133c was not connetd only to my PC, so no ping, Dude or whatelse where running...Looking around the forum, this seems to be a known problem.

Rgds

cpresto:
you wrote

This is evidence that CPU resources are not enough, hope that new RB411 gives better results...

I think that is not true. It proves something else is wrong, config, bad cable connection or anything else. The CPU power of the rb133c's is sufficiant to all the things you try to do at ease. It could also be you have a board that is not OK. In that case you should contact your supplier for an rma.

Like said, MT is probably selling the rb133c's by the thousands and so far I see only two guys on this forum complaining about the CPU and to readers it is not even clear what they exactly want... or see....
There are guys running hundreds of these boards in production. I do about 60 of them and we have no problems with the CPU power. It spikes sometimes to 100% but that is to be expected and very normal...
On average the CPU's work at 10-30% of the cpu capacity under full load circumstances (3Mb traffic with firewalls, natting and routing. ) I can move files in and out the CPE at 20Mb, I can run an export, all little load on the CPU.
Rudy

I also have a client (RB112, ROS3.4) that is at 50-100% cpu all the time, with only about 1mbit/s throughput, is this normal?

We have a mesh with 9 RB112s. Working fine for six months on 2.9.xx . We upgraded all to 3.3 and now 4 of them have crashed inside 2 days. CPU stays on 100% and I cannot see anything in winbox or terminal.

I only installed the following packages: routerboard, system, wireless, NTP, routing, security.

We have Dude running but I have turned off polling on this network to see if that helps.

Well I though that only I who got the problem.. I have RB133c with ROS 3.xx, not just
the CPU became 100%, the booting is taking soo long, even became fail then restart..

I downgrade to 2.9.xx everything normal...

I have a mesh of about 50 RB532s running a simple bridged
wds backhaul with 3 client APs per node. All were running
various versions of 2.9 no problem 0-20% CPU. I had a couple
test nodes running 3.7 ok so I upgraded about half of my
network to 3.7 and now the upgraded units run 80-100%
CPU and reboot frequently - I used to expect uptimes of
200 days now I'm lucky to see 2 days. Any ideas/suggestions?
I'm considering going back to 2.9.51 and staying there.
Thanks

From what I've seen around the forum....go back to 2.9.51....

Rgds

Nothing like answering your own question... This might work
for others too...

Fortunately, having a variety of RBs (100s & 500s) of varying
vintages, configurations, radio revisions (Atheros only - Engenius)
it dawned on me that the only nodes with this problem had
radios in them. I started tinkering with one of the nodes with
0 (zero) clients and 100% CPU and took CPU down to 0-20%
by disabling the AP radios. Well, there's not much use to that
as a WISP... I re-enabled the radios and CPU went back to
100%. I disabled all radios save for 1 and still had 80% CPU.
I went through all the radio settings I'm not that familiar with
and found that disabling the "Adaptive Noise Immunity" on the
"Advanced" tab (you have to be in "Advanced Mode" to see
this option) the CPU dropped to a normal 0-20%. I re-enabled
all the radios and disabled ANI on all and CPU is still normal 0-20%.
My RF environment is like pea-soup here - tightly packed real
estate, and every tom, dick and harry with a 20 year old
microwave oven, wireless security cams, 5 cordless phones
and sharing their $15/month DSL with all their neighbors. I pat
myself on the back every time I actually make something work...

Net result: Disabling ANI fixed my 100% CPU problem.

I take no responsibility for anyone else trying this on their systems.

Nothing like answering your own question... This might work
for others too...

Net result: Disabling ANI fixed my 100% CPU problem.

You're right.

For example, I just had a site running an RB112, ROS 3.6, SR9 + Compex 200mW b/g card. Both interfaces had ANI enabled and the CPU showed 100% usage nearly constantly.

Now, with ANI disabled, the CPU generally stays under 10%, with a rare spike to 100% (I'm the only load on this RB at the moment)

Throughput is up, winbox fully loads instantly (1-2s) by comparison (before turning it off there was >15 second lag before the interface list would show up) and the terminal window doesn't 'act' like a 300 baud serial console.

Now if only MT tested their software, or gave the user some sort of way to diagnose their own problems beyond blindly 'flipping switches'... Putting it nicely - I look forward to the day I no longer need MT's software or hardware. Luckily that day is rapidly approaching.

Glad it worked! I started off with Cisc*/Air*net and almost
walked away from the business/industry because their products
were so absolutely brain-dead non-functional (I still have some
running and they are a constant source of trouble.) IMO, I
wouldn't be so harsh on MT - I worked on a very similar
software team long ago (BorderWare Firewall Server) and I
swear by MT's hardware and software (well, maybe not 3.x)
but I would hazard a guess the problems are due more to
the product managers and not the developers. To their
credit, they are actually talking to me about this and
other issues. mike

Glad it worked! I started off with Cisc*/Air*net and almost
walked away from the business/industry because their products
were so absolutely brain-dead non-functional (I still have some
running and they are a constant source of trouble.) IMO, I
wouldn't be so harsh on MT - I worked on a very similar
software team long ago (BorderWare Firewall Server) and I
swear by MT's hardware and software (well, maybe not 3.x)
but I would hazard a guess the problems are due more to
the product managers and not the developers. To their
credit, they are actually talking to me about this and
other issues. mike

I've ran into a few show-stopper issues that have caused a lot of anger here. The largest problem I've got right now with my MT gear is the completely broken rate control algorithm. I'd also like my SR9 interfaces to actually show up reliably after reboot in 3.x (witnessed the problem last night with 3.7 - I've seen it on various hardware configs - 112, 133, 133c and 532, with various age SR9's, and various ages of routerboot [2.12 doesn't fix it])

But, at least 3.4-and-up doesn't have random disassociation 'spasms' like 2.9.46-51 did for me. Guess I traded one set of bugs for another.