[Help] VOICE (UDP) over RB333 < 2km

RouterOS Wireless Networking
1

Hi all,
We are trying a link for a voice (VOIP) provider using RB 333. Distance around 2km, LOS. using 2ghz-10Mhz band.

signal strength for both side were -39db to -41db

The problem is, whenever the traffic hits 700kbps or more, the ping time goes high above 600ms. then drops after 10-20pings.
(This would be quite annoying to the voip clients.)

But then traffic below 700kbps, ping went normal, about 3-4ms.
When there’s no traffic at all it was <3ms.

tried different frequency band (5Ghz, 2g-10mhz), but still the same.

Bandwidth testing with UDP, shows 4mbps up and 4 mbps, while ping time sit still at 2digits.

Anyone has the same experience? How to fix please…

Thx in advance

2

I haven’t experiened such high signals but many will suggest that you actually have too much power which is overdriving the receiver… can you try turning down the transmit power or misaligning the antennas to get it more in the -50 to -60 range and see if it makes a difference? It would at least prove wether that’s the cause or not.

3

i’m only operating it on 18db tx power.

using NMP8602 mPCI…

:frowning:

4

as jcremin mentioned your power is a bit too high, but tolerable … what should help is turning on nstreme … it has saved my back and sanity many times …


I.e without nstreme pings = 400ms … with nstreme 2ms. Your results may vary but should be similar …

Regards.

5

How many calls were going over this link?

700kbps doesn’t sound like alot, but it really comes down to pps (packets per second).
It would be good to know these numbers, as voip packets are small, but the pps is big.

Could it be that you will have to wait for the RB600?
It is possible that you are maxing on the pps capabilities of the rb333.

6

We had about 43-45 calls when it hits 700kbps, but sometimes 63calls but most calls dropped because the latency hits 3 digits stable… :frowning:
Haven;t noted the pps, but i’m sure it;s pretty high. I’ll check again.

Use pc routers with same mPCI signal strengh was the same -39db - -45dbi, higher thruput, but does the same, whenever bandwidth reaches > 700kbps the latency goes high.

Using 2.3Ghz frequency now, throughput at the moment is 9-10mbps (both), i wonder if that helps.
If not, might try nstreme like warwick09 suggested.

…

7

I’ve been testing some XR9’s. When my signal hit -38ish, pings were out there, CCQ is around 30%. YMMV. I’d try getting it in the -50 range, that is the target high signal these cards are designed to run.

8

ilius168 -
As a long time user of MT, let me make an observation or two and a few suggestions…

Nstreme - if you can maintain at least 5 - 10 % traffic load on that wireless circuit then Nstreme will help you. If you cannot then when traffic is low your VoIP calls will have issues. Why - because VoIP packets are very small and it takes a lot of them to fill up the default Nstreme packet size - that takes time - thus a delay in the packet getting trasmitted.

I see you were using the 10Mhz channel - you realize that MAX bps is about 9Mbps under ‘ideal’ conditions. I would highly reccommend that you use a ‘standard’ 20mhz channel, and find one that gives you near perfect CCQ of 100%. That would give you 20 - 25 Mbps of capacity.

Lastly you say traffic - so I am assuming that you don’t mean just VoIP. Set up firewall/mangle and queues to identify and prioritize VoIP, and your other traffic. I set my VoIP to priority=2, most everything else is priority 5, 6, and 7. The ONLY thing I have as pri=1 is management ‘stuff’ (that why I never have to wait to do something…most of it is text based anyway so it is a very low overhead proposition)…

9

Hi thanks all for the tips!
Had traffic load of 800kbps, ping stays at 1 digit.
Using 2.4Ghz-only-G band with superchanels seems to work. CCQ is 100%/98% most of the time. Bandwidth tested 28mbps oneway while average 13mbps on both tx/rx.
(too bad, G-Turbo mode doesn’t work on my RB 333)

traffic = those UDP packets, no other except winbox :wink:

Shown on the mrtg, CPU gets high when traffic gets high, is that normal? Memory usage normal ± 12-16mb

PS: Can someone tell me how to activate NTP, since RB doesn’t have battery to store it’s time? :smiley:

10

the rb333 is report to be capable of 75000 pps.
that said, I would have to say that under simplistic scenarios this may be true, but what happens once you add firewall rules, wireless, etc.

These all take resource from the cpu, so 75000 is ideal but not likely.

compare this to the 120000 pps of the rb600 and you will see that you will most certainly be better off.

Try using the rb333 with a single radio and only routing (no firewall etc) routed to a more powerfull PC based router, and out from there.
keep the config on the rb333 as simple as possible and with as little packages instaled and/or enabled as is possible, this will allow you to off-load the more demanding tasks of firewalling, and outher things to a more powerull machine.

11

The problem may not be the pps capability, it could be just the throughput problem.
Currently the traffic never hits as high as 75,000pps, max that we’ve observed were <2000pps (around 800-900kbps).

No firewall running, just plain routing & simple queue for 5 ip addresses, just for graphing purposes, no bandwidth management neither :slight_smile:

12

ilius168 -
The 75,000pps is for a wired connection - not wireless…

It is typical to see the cpu utilization to rise as the wireless throughput is increased. That being said, we have put 50mbps (TCP) through an RB333 and the cpu tops out at about 85%. This is with two radios and one ethernet connection. Bonding, EoIP tunnels, & Nstreme.

Things that contribute to cpu utilization are just like tgrand said, firewall rules, filtering, multiple radio cards, etc. Also wireless errors increase cpu load because the packet has to be re-transmitted. Your error rate is VERY low so not really an issue for you - did you happen to look at your CCQ during your peak load? It could have been higher = higher cpu loading.

In your case most (all?) of your traffic is UDP / VoIP, small packets and a lot of them…EVERY packet takes time to format and send out. EVERY packet has the same ‘header info’ made for it each time. EVERY packet requires time for it’s transmit window. So, as in your case, there are alot of small packets to format and be sent, that eats up cpu time. When you have ‘full size’ or nstreme packets, there is less time spent formatting because you are sending more data per packet, (less packet formatting = less cpu utilization), less wait time between packets because you send bigger packets - well you get the picture…

Things that can help are turing off any packages you don’t need like, hotspot, dhcp, etc. Removing them is even better - you can always add them back later. Latest ROS rc is also a little better at memory / task management so that should help you as long as you keep the RB updated (don’t update the very first day a new ROS comes out…give it a few days to a week, check the forum for new issues with the new ROS, if none of the newly reported issues affect you then upgrade…).

System / Packages / look for the NTP or SNTP (depends on what you loaded the system with…). Enable it, restart your RB. Once restarted, go to system, (S)NTP, then set your time servers, time zone, wait about 5 minutes and your time should be set…

Thom