Hello,
We have AP (RB411A) with about 60 clients on it (mix of RB133C & RB411).
Nstreme is enable. Polling is enable.
We use WDS and bridge at the CPE side.
VoIP to the user (i.e. AP → CPE → User) is pretty good.
However, coming back (i.e. User → CPE → AP) is horrible.
This happens even when the AP isn’t passing more than about 1Mbps of data.
Anyone have suggestion as to what we should do to solve this problem?
Have you tried installing the new Nstream test package?
I noticed VOIP over nstreme was also choppy and not very responsive. I had the option to disable nstreme and found that it sorted out the problem. I would assume it has someting to do with the way nstreme re-packages data packets into larger formats. Voip traffic requires steady constant bandwidth.
I too found out that enabling nstream would degrade voip considerably.
-Michael
sigh Wish I would have known that a month ago. When the wireless beta package was released for 3.17 a while back, we put it on the AP’s and noticed a huge improvement in latency/etc so we converted all our CPEs back to Nstreme. Converting them off Nstreme again will be such a headache.
If I do that, do you suggest using the new RTS/CTS that MikroTik has, or just letting the thing run rampant?
My opinion is your ap to client density too high for quality voip services. If you have say 30 / or 15 users per ap do you still have problem? Time slicing between 60 clients has to kill your latency even if jitter is controlled by polling mechanism.
Scott
I am having this problem too. Have you guys figured it out yet as I am curious as to what to do. VOIP PBX Skype
Thanks
Jim
Did either of you try reducing clients/AP and, if so, was it effective? Thanks.
Try this
/system script
add name="ChangeBand" \
source=":local delais 5s\r\n:local liste 2.4ghz-b/g,2ghz-5mhz,2ghz-10mhz;\r\n \
\r\n:foreach band in=\$liste \
do={\r\n:if (![/interface wireless get wlan1 running]) do={\r\n/interface \
wireless set wlan1 band=\$band\r\n:delay \$delais\r\n}\r\n}\r\n\r\n:if \
(![/interface wireless get wlan1 running]) \\\r\ndo={\r\n :if \
[/interface wireless nstreme get wlan1 enable-nstreme] \\\r\n do={\r\n \
/interface wireless nstreme set wlan1 enable-nstreme=no\r\n } \
else={\r\n /interface wireless nstreme set wlan1 \
enable-nstreme=yes\r\n }\r\n}"
/system scheduler
add comment="" disabled=no interval=20s name="schedcheckWifi" \
on-event=ChangeBand start-time=startup
Not my work, someone else on the forum made this. Changes from 5MHz/10MHz/20MHz with Nstreme on or off until it gets a lock. Works like a charm. I can change anything on my system aside from turbo and never have to touch the CPE.
Could this be helped with WMM? I haven’t used it; but it looks to provide pretty good QOS at the radio layer.
interester, i have a similar problem!!
Oldman, I have been quite successfully using the script you provided in this forum, but lately I have been working on a rebuild script and attempting to clean up some old configs with a system reset run-after-reset. When I import your script in this manner it says that the owner is *sys and it will not work for me. If I copy paste the script in it has an owner of “admin”. How do I get it to import during a run-after-reset, but still work properly? Your help would be greatly apprectiated as I have very little knowledge in scripting.
This looks like two different threads were merged when they are totally unrelated.
The latest versions of nstreme work great with VoIP.
We have over 100 calls running at the same time over one such link.
I am not too good at scripting myself, just getting started. As a matter of fact I am having a hard time editing that script to work with 5GHz, enabling N mode, etc…
Ok, you have to clearify this:
You have 100 calls (different client’s) running over one backhaul “link”?
Or you have 100 different client (and making calls) running off one AP?
The latter seems to me asking for big problems, Voip or no Voip, nstreme or no nstreme.
But running 100 or more (1000!) over a big enough pipe is no problem. In fact, the more traffic a link gets the better the result of nstreme is…
What I want to know, in a 20-50 AP-CPE network does nstreme has any improvement for VOIP (short packages) over proper configured (with RTS/CTS) AP-CPE network?
In the old versions nstreme was not a good solucion for low traffic running links (like CPE to AP) because the advantage of nstreme is speed increase by combining packages in bigger frames to avoid too much overhead data. But Voip doesn’t like delays and when nstreme is waiting for a bit more date to form a big package this will delay the voip package.
But mayby the new nstreme found a workaround for this? Setting frame size to small size? But then you partially loose the benefit of nstreme as well?
Please correct me if I am wrong… 
100 calls on one backhaul link. Not 100 clients on one AP. That’s crazy.
Yes, nstreme is better than RTS/CTS on Mikrotik. You can also try IP packing.
OK,
Can you explain to me why you do think that nstreme is better? Is this just a ´hinge´ or did you really try and experienced differences?
I am asking because to me (and not only me) the pure working principle (collecting frames before sending so overhead can be skipped and thus higher throughputs will be achieved) of nstreme implements that short package services (like VOIP) are suffering. Or you have to set framer policy such that short packages still pass fast, but in that case we thrown away the advantage of nstreme.
I don’t believe nstreme can do both at the same time.
(To me it is a theoretical discussion anyway for PtMP since all my networks have no-MT devices is it. I only have some back hauls where I could use is. But these are at times also very idle and then I still want to have my traffic pass with lowest latency possible.)
I did an actual real life comparison - multiple times.
We have many retail and wholesale customers with large quantities of VoIP traffic.
Here is a simple example.
You have 10 active VoIP lines. Each line sends 50 packets per second per direction. That’s 500 packets per second.
Now suppose you enable nstreme and instead of sending each packet by itself, you collect 10 packets before sending it across the wireless link.
You are now sending only 50, larger, packets per second. You are saving a TON of bandwidth and air time because your overhead is MUCH lower.
Remember, since there are 10 phone lines, these 10 packets are generated all at the SAME time.
Nstreme does not need to “sit and wait” for frames.
In a PtMP setup, the savings are of course much smaller.
Still, if you collect 10/50th of a second worth of packets before sending them - the customer won’t notice and your network will run better.
I did an actual real life comparison - multiple times.
We have many retail and wholesale customers with large quantities of VoIP traffic.Here is a simple example.
You have 10 active VoIP lines. Each line sends 50 packets per second per direction. That’s 500 packets per second.
Now suppose you enable nstreme and instead of sending each packet by itself, you collect 10 packets before sending it across the wireless link.
You are now sending only 50, larger, packets per second. You are saving a TON of bandwidth and air time because your overhead is MUCH lower.Remember, since there are 10 phone lines, these 10 packets are generated all at the SAME time.
Nstreme does not need to “sit and wait” for frames.In a PtMP setup, the savings are of course much smaller.
Still, if you collect 10/50th of a second worth of packets before sending them - the customer won’t notice and your network will run better.
OK, I agree. But what happens now if in the evening or night, when most phone lines will be dead and other traffic will be low and only one or two callers use the service?
I mean, I have almost 200 users and still at times I see only tenths of kbps flowing through my main gateway. Meaning that further down into my network there will be occasions that only one voip call needs to run over a otherwise idle back haul.
I see many examples like yours always go from the situation that plenty traffic is around and the operator wants as much data pushed as fast as possible with the lowest possible delay under such circumstances.
But in real life most lines will see ´heavy´use only during some peak hours, mediate use during most of the day but low to zero usage during considerable time of the nights. Depending on the client base and size of the network off course.
So, although nstreme could give me that extra speed and capacity during peak and mediate hours, the same nstreme will not benefit near idle running lines? I have been reading about it in the past that some operators sensed such behaviours. But maybe this is just an old idea not valid any more with new nstreme?
New nstreme fixed the unstable latency during low traffic.
Type less, test more