I'm really starting to miss Nstreme lately. I used to have a solid 1-2ms latency all day long. Now my PtP required more throughput, so I had to change up to 2x2 MIMO. Data rates are GREAT, throughput rocks at 197mb UDP and 160 TCP. However, the latency is all over the place, with high jitter. Example:

9ms
8ms
8ms
13ms
6ms
13ms
13ms
7ms
4ms
13ms
7ms
9ms
7ms
6ms
5ms
5ms
6ms
17ms
7ms

And so on.. this is even with running v6.1. Is there any tricks in tuning any settings to get a more "solid" or lower latency? This really adds up when I have a chain of 6 PtP's stretching over 120 miles. Nstreme I used to be able to get under 10ms total all the way to the end and back. Now through all the PtP's and "NV2", its around 25-45ms! and jitter all over the place!

Wish they would just fix Nstreme to work better with 2X2. Nstreme was perfect for PtP applications, while NV2 is designed more for PtMP.

Hi wispwest, I've noticed same behaviour when I was updating from 5.25 to 6.0 and all my <1ms PtMP links increased both latency and jitter. Going back to 5.25 or 5.20 did not help at all: with unchanged settings worse results... really annoying! I'm currently trying to find a most satisfying config but no luck yet. Setups that work better are only Nstreme and 802.11 in terms of latency around 1ms. But Nstreme is unstable and even bouncing the SXT. 802.11 is not suitable for PtMP. If I could turn back time...

EDIT: now after some playing with the wlan interface setting I've found the jitter killer, I guess: it's the "Multicast Helper" on page "Wireless" that needs to be set on "full" to have stable latency of 1 to 4 ms roundtrip between AP and station (again). Sounds strange but it was the only setting that will let nv2 have low latency and decreased jitter. Made this setting on both AP and station. Throughput is fine - latency keeps low. Hooray!

That did work! YES!!!!!!! Thank you so much how did you find that out!?!?!

update: had to turn it back off. I started having OSPF issues wigging out and dropping ;(

How I found it out? as I said: by playing with the settings... in a lab environment and a hundred combinations I excluded several settings that would make sense,up to this one which absolutely makes no sense to me
Well, regarding your OSPF issue I would try this post from gregsowell: http://forum.mikrotik.com/viewtopic.php ... 25#p335193
As the setting I found deals with multicast and OSPF does either, you probably could switch from multicast to unicast?
I'm not that familiar with OSPF, but it sounds reasonable that it could work... good luck!

Only options I see for OSPF are Broadcast, nbma, point to point, and ptmp

my example:

ptp first jump ALCOMA

64 bytes from 10.55.4.1: icmp_req=1 ttl=63 time=0.828 ms
64 bytes from 10.55.4.1: icmp_req=2 ttl=63 time=0.822 ms
64 bytes from 10.55.4.1: icmp_req=3 ttl=63 time=0.874 ms
64 bytes from 10.55.4.1: icmp_req=4 ttl=63 time=0.885 ms
64 bytes from 10.55.4.1: icmp_req=5 ttl=63 time=1.01 ms
64 bytes from 10.55.4.1: icmp_req=6 ttl=63 time=0.729 ms
64 bytes from 10.55.4.1: icmp_req=7 ttl=63 time=0.796 ms
64 bytes from 10.55.4.1: icmp_req=8 ttl=63 time=0.719 ms
64 bytes from 10.55.4.1: icmp_req=9 ttl=63 time=0.714 ms
64 bytes from 10.55.4.1: icmp_req=10 ttl=63 time=0.746 ms
64 bytes from 10.55.4.1: icmp_req=11 ttl=63 time=0.801 ms
64 bytes from 10.55.4.1: icmp_req=12 ttl=63 time=0.719 ms
64 bytes from 10.55.4.1: icmp_req=13 ttl=63 time=0.737 ms
64 bytes from 10.55.4.1: icmp_req=14 ttl=63 time=0.766 ms
64 bytes from 10.55.4.1: icmp_req=15 ttl=63 time=0.723 ms
^C
--- 10.55.4.1 ping statistics ---
15 packets transmitted, 15 received, 0% packet loss, time 13998ms
rtt min/avg/max/mdev = 0.714/0.791/1.017/0.088 ms

second jump NV2 MIMO 1x1 2x20MHz

64 bytes from 10.55.3.1: icmp_req=1 ttl=60 time=17.5 ms
64 bytes from 10.55.3.1: icmp_req=2 ttl=60 time=3.77 ms
64 bytes from 10.55.3.1: icmp_req=3 ttl=60 time=4.05 ms
64 bytes from 10.55.3.1: icmp_req=4 ttl=60 time=4.10 ms
64 bytes from 10.55.3.1: icmp_req=5 ttl=60 time=3.10 ms
64 bytes from 10.55.3.1: icmp_req=6 ttl=60 time=8.41 ms
64 bytes from 10.55.3.1: icmp_req=7 ttl=60 time=8.81 ms
64 bytes from 10.55.3.1: icmp_req=8 ttl=60 time=4.06 ms
64 bytes from 10.55.3.1: icmp_req=9 ttl=60 time=3.54 ms
64 bytes from 10.55.3.1: icmp_req=10 ttl=60 time=5.32 ms
64 bytes from 10.55.3.1: icmp_req=11 ttl=60 time=4.60 ms
64 bytes from 10.55.3.1: icmp_req=12 ttl=60 time=22.0 ms
64 bytes from 10.55.3.1: icmp_req=13 ttl=60 time=6.84 ms
64 bytes from 10.55.3.1: icmp_req=14 ttl=60 time=2.63 ms
64 bytes from 10.55.3.1: icmp_req=15 ttl=60 time=2.97 ms
64 bytes from 10.55.3.1: icmp_req=16 ttl=60 time=3.28 ms
64 bytes from 10.55.3.1: icmp_req=17 ttl=60 time=15.0 ms
64 bytes from 10.55.3.1: icmp_req=18 ttl=60 time=8.56 ms
^C
--- 10.55.3.1 ping statistics ---
18 packets transmitted, 18 received, 0% packet loss, time 17022ms
rtt min/avg/max/mdev = 2.633/7.150/22.040/5.426 ms

third jump NV2 MIMO 1x1 2x20MHz

64 bytes from 10.55.2.1: icmp_req=1 ttl=58 time=7.00 ms
64 bytes from 10.55.2.1: icmp_req=2 ttl=58 time=7.53 ms
64 bytes from 10.55.2.1: icmp_req=3 ttl=58 time=8.56 ms
64 bytes from 10.55.2.1: icmp_req=4 ttl=58 time=15.4 ms
64 bytes from 10.55.2.1: icmp_req=5 ttl=58 time=7.69 ms
64 bytes from 10.55.2.1: icmp_req=6 ttl=58 time=19.4 ms
64 bytes from 10.55.2.1: icmp_req=7 ttl=58 time=4.74 ms
64 bytes from 10.55.2.1: icmp_req=8 ttl=58 time=6.89 ms
64 bytes from 10.55.2.1: icmp_req=9 ttl=58 time=4.58 ms
64 bytes from 10.55.2.1: icmp_req=10 ttl=58 time=10.6 ms
64 bytes from 10.55.2.1: icmp_req=11 ttl=58 time=6.31 ms
64 bytes from 10.55.2.1: icmp_req=12 ttl=58 time=13.4 ms
64 bytes from 10.55.2.1: icmp_req=13 ttl=58 time=7.77 ms
64 bytes from 10.55.2.1: icmp_req=14 ttl=58 time=10.2 ms
64 bytes from 10.55.2.1: icmp_req=15 ttl=58 time=7.06 ms
64 bytes from 10.55.2.1: icmp_req=16 ttl=58 time=6.46 ms
64 bytes from 10.55.2.1: icmp_req=17 ttl=58 time=6.91 ms
64 bytes from 10.55.2.1: icmp_req=18 ttl=58 time=10.2 ms
64 bytes from 10.55.2.1: icmp_req=19 ttl=58 time=8.49 ms
64 bytes from 10.55.2.1: icmp_req=20 ttl=58 time=8.69 ms
^C
--- 10.55.2.1 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19026ms
rtt min/avg/max/mdev = 4.589/8.916/19.466/3.537 ms

fourth jump NV2 MIMO 2x2 1x20MHz

64 bytes from 10.55.1.129: icmp_req=1 ttl=56 time=10.5 ms
64 bytes from 10.55.1.129: icmp_req=2 ttl=56 time=12.5 ms
64 bytes from 10.55.1.129: icmp_req=3 ttl=56 time=13.3 ms
64 bytes from 10.55.1.129: icmp_req=4 ttl=56 time=19.0 ms
64 bytes from 10.55.1.129: icmp_req=5 ttl=56 time=9.04 ms
64 bytes from 10.55.1.129: icmp_req=6 ttl=56 time=14.6 ms
64 bytes from 10.55.1.129: icmp_req=7 ttl=56 time=9.81 ms
64 bytes from 10.55.1.129: icmp_req=8 ttl=56 time=17.0 ms
64 bytes from 10.55.1.129: icmp_req=9 ttl=56 time=12.5 ms
64 bytes from 10.55.1.129: icmp_req=10 ttl=56 time=10.1 ms
64 bytes from 10.55.1.129: icmp_req=11 ttl=56 time=8.73 ms
64 bytes from 10.55.1.129: icmp_req=12 ttl=56 time=13.9 ms
64 bytes from 10.55.1.129: icmp_req=13 ttl=56 time=13.5 ms
64 bytes from 10.55.1.129: icmp_req=14 ttl=56 time=13.1 ms
64 bytes from 10.55.1.129: icmp_req=15 ttl=56 time=10.8 ms
64 bytes from 10.55.1.129: icmp_req=16 ttl=56 time=10.3 ms
64 bytes from 10.55.1.129: icmp_req=17 ttl=56 time=8.72 ms
64 bytes from 10.55.1.129: icmp_req=18 ttl=56 time=12.6 ms
64 bytes from 10.55.1.129: icmp_req=19 ttl=56 time=15.8 ms
^C
--- 10.55.1.129 ping statistics ---
19 packets transmitted, 19 received, 0% packet loss, time 18028ms
rtt min/avg/max/mdev = 8.724/12.451/19.097/2.805 ms

fifth last jump NV2 MIMO2x2 1x20MHz

64 bytes from 10.55.1.1: icmp_req=1 ttl=54 time=14.3 ms
64 bytes from 10.55.1.1: icmp_req=2 ttl=54 time=18.3 ms
64 bytes from 10.55.1.1: icmp_req=3 ttl=54 time=28.3 ms
64 bytes from 10.55.1.1: icmp_req=4 ttl=54 time=16.6 ms
64 bytes from 10.55.1.1: icmp_req=5 ttl=54 time=13.6 ms
64 bytes from 10.55.1.1: icmp_req=6 ttl=54 time=14.2 ms
64 bytes from 10.55.1.1: icmp_req=7 ttl=54 time=14.1 ms
64 bytes from 10.55.1.1: icmp_req=8 ttl=54 time=14.7 ms
64 bytes from 10.55.1.1: icmp_req=9 ttl=54 time=14.3 ms
64 bytes from 10.55.1.1: icmp_req=10 ttl=54 time=11.4 ms
64 bytes from 10.55.1.1: icmp_req=11 ttl=54 time=12.5 ms
64 bytes from 10.55.1.1: icmp_req=12 ttl=54 time=19.4 ms
64 bytes from 10.55.1.1: icmp_req=13 ttl=54 time=20.7 ms
64 bytes from 10.55.1.1: icmp_req=14 ttl=54 time=19.5 ms
64 bytes from 10.55.1.1: icmp_req=15 ttl=54 time=24.9 ms
64 bytes from 10.55.1.1: icmp_req=16 ttl=54 time=19.4 ms
64 bytes from 10.55.1.1: icmp_req=17 ttl=54 time=31.9 ms
64 bytes from 10.55.1.1: icmp_req=18 ttl=54 time=28.0 ms
64 bytes from 10.55.1.1: icmp_req=19 ttl=54 time=12.7 ms
^C
--- 10.55.1.1 ping statistics ---
19 packets transmitted, 19 received, 0% packet loss, time 18016ms
rtt min/avg/max/mdev = 11.499/18.419/31.919/5.843 ms

don't know what the above pings should prove/show...

but I was referring to this:
"I would try setting my interface types to NMBA(nonbroadcast multi access) and configuring some OSPF neighbors. This will kill multicast and switch all communication to unicast."

You're probably kidding?

Do not want to show here listing pings from the log Nstreme This is to show how NV2 is unfinished and unstable in terms of latency!
I was especially troubling to this issue that developers have devised in Mikrotik NV2, which makes such a problems instead should rather fix the current nstream for 802.11n MIMO 2x2.

on what links you tested that multicast-helpers - distance?
During the test the traffic was also going or just the pings?

Distance connections is about to 5km up to the first joint NV2 is 3.4 km 5 km second third fourth 300 m 250m. Ping was running at low load connections to about 10Mb. All connections are clean but in the radio environment and have CCQ from 90% to 100%.

so you are testing from a windows PC that is connected to the first wireless router and then you do a ping to all the five wireless routers.
Could you post the results from the setup where you have the multicast-helper disabled/default value and then where you have specified to full so we could see the difference?

I face similar behavior on NV2 PtP Links: jitter ( 5-15 ms rtt ). never tried out nstream on such links and as the network is stable in general i have resigned to get rid of that jitter. As we are planing to extend our network with more chained ptp link it would be nice to solve this issue somehow.

it would be nice to solve this issue somehow.

+1

+1 Yes Mikrotik kill the nv2 jitter

Hi, new findings after a lot of testing (currently with 6.1): after doing a "Reset Configuration" with "No Default Configuration" and turning off CPU eating things like Conn. Tracker, I got a good RTT with minimum jitter going back and forth from 2ms to 4ms running none or low traffic (only ping) as well as heavy traffic (500 Meg file download between 2 Windows machines across the PtP Bridge --> over 90Mbps real throughput measured under ROS and Windows). All this without the Multicast Helper but using NV2! Feels much better now... but there must be an ultimate tweak to get it as good as nstreme's jitter and RTT

Hi, new findings after a lot of testing (currently with 6.1): after doing a "Reset Configuration" with "No Default Configuration" and turning off CPU eating things like Conn. Tracker, I got a good RTT with minimum jitter going back and forth from 2ms to 4ms running none or low traffic (only ping) as well as heavy traffic (500 Meg file download between 2 Windows machines across the PtP Bridge --> over 90Mbps real throughput measured under ROS and Windows). All this without the Multicast Helper but using NV2! Feels much better now... but there must be an ultimate tweak to get it as good as nstreme's jitter and RTT

Can you confirm results were poor using 5.20 also is this on a routed or bridged network?

1.5km PtP nv2 bridge with 2x SXTG. This is 5 minutes of ping, average ping over 5 minutes, 3ms.
SXTG's are in WDS bridge, pings are performed from routers that are behind both SXTGs. ROS 6.1.

Same result with or without other traffic running on the link.

Hi, new findings after a lot of testing (currently with 6.1): after doing a "Reset Configuration" with "No Default Configuration" and turning off CPU eating things like Conn. Tracker, I got a good RTT with minimum jitter going back and forth from 2ms to 4ms running none or low traffic (only ping) as well as heavy traffic (500 Meg file download between 2 Windows machines across the PtP Bridge --> over 90Mbps real throughput measured under ROS and Windows). All this without the Multicast Helper but using NV2! Feels much better now... but there must be an ultimate tweak to get it as good as nstreme's jitter and RTT

Can you confirm results were poor using 5.20 also is this on a routed or bridged network?

I would hazard that it was better with 5.x in general, but since version 6 (I upgraded from 5.25 to 6.0) all my PtMP links increased RTT and jitter. Same behaviour I saw then with PtP links I was building recently.
I have fully bridged network.
Maybe I missed something during upgrade?

Do you have knowledge on how to setup the nv2 with settings that are stable and fast? Thanks in advance!

................................................................

I would hazard that it was better with 5.x in general, but since version 6 (I upgraded from 5.25 to 6.0) all my PtMP links increased RTT and jitter. Same behaviour I saw then with PtP links I was building recently.
I have fully bridged network.
Maybe I missed something during upgrade?

Do you have knowledge on how to setup the nv2 with settings that are stable and fast? Thanks in advance!

I have the same issues with NV2 using 5.20 on a routed network, we are all looking for ways to improve NV2, and it would appear that if using Mikrotik for PTP's, two types of links are required (1) NV2 for high throughput (2) 802.11x for low latency.

Had same hight latency and jitter on simple .5km ptplink with 2x SXT ver 6.2

I now have steady 3ms.

I discovered that NV2 needs continuous data flow of at least 1MB x 1MB

I set a 1MB x 1MB bandwidwidth test running between point a and point b.

While the data was flowing low latency almost zero jitter.

as soon as I stop the bandwidth test latency and Jitter hits the roof again

Hope this info is useful