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

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. Residential Voip Cheap Voip

Thanks

Jim

*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.

/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

*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.

Try this

Code: Select all

/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.

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.

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?

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?

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.

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 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.

But maybe this is just an old idea not valid any more with new nstreme?