I just bought 2 SXT G-5HPnD's and used the following guide to set them up in bridge mode:

http://www.wispforum.net/entry.php?5-Ho ... ode-Part-I

The reason I bought them was to set them up in a ~300m bridge with the goal of achieving the lowest latency possible while maintaining 60Mbps downlink speeds. I was originally looking at some Ubiquiti nanobridges but one of the guys on their forum said he thought nstreme was the only thing that might be able to get the latency I'm looking for. See original thread here:

http://forum.ubnt.com/showthread.php?t=53852

Unfortunately after settings them up my ping is varying between 5-10ms. I'm sure we can get it down. I'm currently reading through the wiki but can you point me in the direction of what settings I should read about to start tuning for low latency?

Thanks

You could try Nstream rather than NV2

According to the wiki nv2 potentially has lower latency (or at least more tunable) than nstream?

http://wiki.mikrotik.com/wiki/Manual:Nv2

According to the wiki nv2 potentially has lower latency (or at least more tunable) than nstream?

http://wiki.mikrotik.com/wiki/Manual:Nv2

Nstreme is still the way to go in p2p setup (latency 1-2ms).
NV2 is good for p2mp but still ping vary too much.

1. RouterOS v5.17 has better latency in Nv2 links
2. Experiment with the HW retries setting http://wiki.mikrotik.com/wiki/Manual:Wi ... retries.3F

1. RouterOS v5.17 has better latency in Nv2 links
2. Experiment with the HW retries setting http://wiki.mikrotik.com/wiki/Manual:Wi ... retries.3F

Thanks for the info.

1. I am using RouterOS v5.17

I did some testing today with the following setup:

Laptop 1---Ethernet---5HPnD station bridge******Wireless Link******5HPnD bridge---Ethernet---Laptop 2

Using nv2, when pinging from Laptop 1 to bridge radio I saw pings between 20ms and 30ms, but only ~7ms from Laptop 2 to the station bridge. (Note: I may have this backwards but I know for sure the behavior was different pinging one way vs the other).

Luckily using nstreme provides much better pings both ways, usually around 0.7-0.8ms with occasional spikes. Any ideas on this behavior?

2. I will look into those settings. If it makes a difference, this bridge will be for a specific purpose and mostly UDP packets will be sent across. It will need to be able to handle TCP packets but the latency on those doesn't matter. So my thinking is for UDP anything having to do with ACKs can be gotten rid of for the most part?

1. RouterOS v5.17 has better latency in Nv2 links
2. Experiment with the HW retries setting http://wiki.mikrotik.com/wiki/Manual:Wi ... retries.3F

Hello. Someone from MT support - perhaps Uldis once wrote on the board that the HW retries setting has no effect if mode is selected NV2.
So which is it?

Sorry my mistake, yes, HW-retries only has effect on Nstreme.

tanders12, try Nstreme, maybe it will work better in your situation

Sorry my mistake, yes, HW-retries only has effect on Nstreme.

tanders12, try Nstreme, maybe it will work better in your situation

Is it possible and I have mentioned this several times before that MT could simply when you select NV2 or Nstream it would grey out (or a simple red X in data field) on setting not used by that wireless protocol, thus avoiding wasted time in trying adjusting these setting.

Sorry my mistake, yes, HW-retries only has effect on Nstreme.

tanders12, try Nstreme, maybe it will work better in your situation

Is it possible and I have mentioned this several times before that MT could simply when you select NV2 or Nstream it would grey out (or a simple red X in data field) on setting not used by that wireless protocol, thus avoiding wasted time in trying adjusting these setting.

correction, it doesn't work only for Nv2, it works for other protocols (both 802 and nstreme)

Yes, as I mentioned above Nstreme does seem to work much better than nv2, but I'm still trying to tune it as much as possible if anyone has more suggestions

correction, it doesn't work only for Nv2, it works for other protocols (both 802 and nstreme)

How is possible tuning NV2 link? Only with TDMA period size?
Everything else has no affect?
Thanks

Hate to be this guy - some of the other operators in our country are reporting latency of 1-2ms on UBNT's airmax stuff - so one supposes its possible on MT as well (being TDD).

We have reasonable results from NV2 in P2P - around 5ms stable but that is as low as we have ever seen.

We are running a RB411AH whit R52Hn card on JRC-29 antenna and receives a ping on 3ms at a distance of 19km.

We are running nv2.

I have poor ping times using NV2 (OS 5.17) on CPE pppoe to AP

[admin@admin] > ping 10.110.11.1
HOST SIZE TTL TIME STATUS
10.110.11.1 56 64 5ms
10.110.11.1 56 64 6ms
10.110.11.1 56 64 5ms
10.110.11.1 56 64 13ms
10.110.11.1 56 64 26ms
10.110.11.1 56 64 28ms
10.110.11.1 56 64 10ms
10.110.11.1 56 64 24ms
10.110.11.1 56 64 14ms
10.110.11.1 56 64 8ms
10.110.11.1 56 64 12ms
10.110.11.1 56 64 64ms
10.110.11.1 56 64 4ms
10.110.11.1 56 64 8ms
10.110.11.1 56 64 7ms
10.110.11.1 56 64 33ms
10.110.11.1 56 64 29ms
10.110.11.1 56 64 12ms
10.110.11.1 56 64 2ms
10.110.11.1 56 64 19ms
Ping PPPoE server on AP

[admin@admin] > ping 10.150.0.86
HOST SIZE TTL TIME STATUS
10.150.0.86 56 64 13ms
10.150.0.86 56 64 16ms
10.150.0.86 56 64 34ms
10.150.0.86 56 64 18ms
10.150.0.86 56 64 9ms
10.150.0.86 56 64 2ms
10.150.0.86 56 64 31ms
10.150.0.86 56 64 34ms
10.150.0.86 56 64 56ms
10.150.0.86 56 64 14ms
10.150.0.86 56 64 33ms
10.150.0.86 56 64 26ms
10.150.0.86 56 64 5ms
10.150.0.86 56 64 19ms
10.150.0.86 56 64 17ms
10.150.0.86 56 64 7ms
10.150.0.86 56 64 5ms
10.150.0.86 56 64 54ms
Ping Wlan interface on AP

I have poor ping times using NV2 (OS 5.17) on CPE pppoe to AP

[admin@admin] > ping 10.110.11.1
HOST SIZE TTL TIME STATUS
10.110.11.1 56 64 5ms
10.110.11.1 56 64 6ms
10.110.11.1 56 64 5ms
10.110.11.1 56 64 13ms
10.110.11.1 56 64 26ms
10.110.11.1 56 64 28ms
10.110.11.1 56 64 10ms
10.110.11.1 56 64 24ms
10.110.11.1 56 64 14ms
10.110.11.1 56 64 8ms
10.110.11.1 56 64 12ms
10.110.11.1 56 64 64ms
10.110.11.1 56 64 4ms
10.110.11.1 56 64 8ms
10.110.11.1 56 64 7ms
10.110.11.1 56 64 33ms
10.110.11.1 56 64 29ms
10.110.11.1 56 64 12ms
10.110.11.1 56 64 2ms
10.110.11.1 56 64 19ms
Ping PPPoE server on AP

[admin@admin] > ping 10.150.0.86
HOST SIZE TTL TIME STATUS
10.150.0.86 56 64 13ms
10.150.0.86 56 64 16ms
10.150.0.86 56 64 34ms
10.150.0.86 56 64 18ms
10.150.0.86 56 64 9ms
10.150.0.86 56 64 2ms
10.150.0.86 56 64 31ms
10.150.0.86 56 64 34ms
10.150.0.86 56 64 56ms
10.150.0.86 56 64 14ms
10.150.0.86 56 64 33ms
10.150.0.86 56 64 26ms
10.150.0.86 56 64 5ms
10.150.0.86 56 64 19ms
10.150.0.86 56 64 17ms
10.150.0.86 56 64 7ms
10.150.0.86 56 64 5ms
10.150.0.86 56 64 54ms
Ping Wlan interface on AP

Its Possible to get better ping.

HOST SIZE TTL TIME STATUS
172.17.11.109 56 64 3ms
172.17.11.109 56 64 6ms
172.17.11.109 56 64 10ms
172.17.11.109 56 64 3ms
172.17.11.109 56 64 4ms
172.17.11.109 56 64 4ms
172.17.11.109 56 64 5ms
172.17.11.109 56 64 2ms
172.17.11.109 56 64 5ms
172.17.11.109 56 64 6ms
172.17.11.109 56 64 7ms
172.17.11.109 56 64 6ms
172.17.11.109 56 64 15ms
172.17.11.109 56 64 6ms
172.17.11.109 56 64 11ms
sent=15 received=15 packet-loss=0% min-rtt=2ms avg-rtt=6ms max-rtt=15ms


/tool bandwidth-test protocol=tcp address=172.17.11.109
status: running
duration: 10s
rx-current: 92.0Mbps
rx-10-second-average: 86.4Mbps
rx-total-average: 86.4Mbps
random-data: no
direction: receive

/tool bandwidth-test protocol=tcp address=172.17.11.109 direction=transmit
status: running
duration: 25s
tx-current: 99.5Mbps
tx-10-second-average: 89.6Mbps
tx-total-average: 85.6Mbps
random-data: no
direction: transmit


23 km Link. nv2. Rb800 - Rb800 . Nosy enviroment. ccq is 91/58 % TX/RX -62/-62 dBm SNR 52 R5hn + Ubnt Rocket dishes (and yes. algin algin algin.. and more algin on the antenna)

23 km Link. nv2. Rb800 - Rb800 . Nosy enviroment. ccq is 91/58 % TX/RX -62/-62 dBm SNR 52 R5hn + Ubnt Rocket dishes (and yes. algin algin algin.. and more algin on the antenna)

Uptill now we used to align the PTP for max CCQ, best signal, even reduce data rates to increase ccq and this was pinging beyond both sides of the PTP but now I must try pinging just the PTP /30 addresses and see if i can reduce ping time.

Spent a hour adjusting and could not reduce ping times, first i noticed the number of packets sent by NV2 is much higher 380 vs. 140,
My personal conclusion about NV2 high pings maybe caused by load CPU % spikes, I base this on another observation that is when I tried to setup a script to reboot a board on high CPU, http://forum.mikrotik.com/viewtopic.php?f=9&t=23362 when I ran test on low CPU load it ran perfectly and all of the samples where shown in the log but running the test with high load (TCP Bandwidth Test to localhost (127.0.0.1).) it would not run fully and most of the time just 2 of the 5 samples were in the log so a average for this script could not be established when the CPU was running at 100% , so from this if a script cannot run fully ( I could have reduced the samples but did not want false alarms ) what else can be effected?
My thoughts if somehow the max CPU load could be limited to 99% and not 100% if this can be achieved.

NV2 Protcol
192.168.1.100 1480 64 25ms
192.168.1.100 1480 64 14ms
192.168.1.100 1480 64 10ms
192.168.1.100 1480 64 26ms
sent=380 received=362 packet-loss=4% min-rtt=4ms avg-rtt=10ms max-rtt=38ms

802.11 Protocol
192.168.1.100 1480 64 4ms
192.168.1.100 1480 64 4ms
192.168.1.100 1480 64 4ms
192.168.1.100 1480 64 4ms
192.168.1.100 1480 64 4ms
sent=140 received=130 packet-loss=7% min-rtt=4ms avg-rtt=14ms max-rtt=38ms

My thoughts if somehow the max CPU load could be limited to 99% and not 100% if this can be achieved.

Would this 99% not be the new 100%? Max = 100%

Sorry my mistake, yes, HW-retries only has effect on Nstreme.

tanders12, try Nstreme, maybe it will work better in your situation

Is it possible and I have mentioned this several times before that MT could simply when you select NV2 or Nstream it would grey out (or a simple red X in data field) on setting not used by that wireless protocol, thus avoiding wasted time in trying adjusting these setting.

n21roadie means that options that are not available in certain mode setting should be greyed out, as I also mentioned before. It creates confusion, you yourself became a victim of it now!

Spent a hour adjusting and could not reduce ping times, first i noticed the number of packets sent by NV2 is much higher 380 vs. 140,
My personal conclusion about NV2 high pings maybe caused by load CPU % spikes, I base this on another observation that is when I tried to setup a script to reboot a board on high CPU, http://forum.mikrotik.com/viewtopic.php?f=9&t=23362 when I ran test on low CPU load it ran perfectly and all of the samples where shown in the log but running the test with high load (TCP Bandwidth Test to localhost (127.0.0.1).) it would not run fully and most of the time just 2 of the 5 samples were in the log so a average for this script could not be established when the CPU was running at 100% , so from this if a script cannot run fully ( I could have reduced the samples but did not want false alarms ) what else can be effected?
My thoughts if somehow the max CPU load could be limited to 99% and not 100% if this can be achieved.

NV2 Protcol
192.168.1.100 1480 64 25ms
192.168.1.100 1480 64 14ms
192.168.1.100 1480 64 10ms
192.168.1.100 1480 64 26ms
sent=380 received=362 packet-loss=4% min-rtt=4ms avg-rtt=10ms max-rtt=38ms

802.11 Protocol
192.168.1.100 1480 64 4ms
192.168.1.100 1480 64 4ms
192.168.1.100 1480 64 4ms
192.168.1.100 1480 64 4ms
192.168.1.100 1480 64 4ms
sent=140 received=130 packet-loss=7% min-rtt=4ms avg-rtt=14ms max-rtt=38ms

I can fully support this.

I have one 344AH AP with 30+ associated clients and in NV2 the average ping times to all CPE's are around 30-35ms on average. Switch to 802.11 and all ping times fall back to around 1,2 ms with an average of 10ms due some high pikes at 30 or so....

5.17 did bring me hardly any improvement in the ping times. Maybe I can distinguish some 1-3ms gain but compared to the average 30-35 that's nothing.
At the same time it brings me disconnecting units so it looks to me 5.17 is going to be a waste of time.

Sorry my mistake, yes, HW-retries only has effect on Nstreme.

tanders12, try Nstreme, maybe it will work better in your situation

Is it possible and I have mentioned this several times before that MT could simply when you select NV2 or Nstream it would grey out (or a simple red X in data field) on setting not used by that wireless protocol, thus avoiding wasted time in trying adjusting these setting.

n21roadie means that options that are not available in certain mode setting should be greyed out, as I also mentioned before. It creates confusion, you yourself became a victim of it now!

Maybe greyed out could cause users to think that the wireless package was not installed fully, so my second suggestion of red X in data field for these setting not used when NV2 is selected is a better solution.

My thoughts if somehow the max CPU load could be limited to 99% and not 100% if this can be achieved.

Would this 99% not be the new 100%? Max = 100%

Correct new max for a processes is 99% and not 100%, is this possible

I can fully support this.

I have one 344AH AP with 30+ associated clients and in NV2 the average ping times to all CPE's are around 30-35ms on average. Switch to 802.11 and all ping times fall back to around 1,2 ms with an average of 10ms due some high pikes at 30 or so....

5.17 did bring me hardly any improvement in the ping times. Maybe I can distinguish some 1-3ms gain but compared to the average 30-35 that's nothing.
At the same time it brings me disconnecting units so it looks to me 5.17 is going to be a waste of time.

I must repeat the ping test this time @100% CPU on both NV2 and 802.11

Another Ping test but this time CPU running at 100% , notice reduction in number of packets sent by each protocol was 380 vs. 140, another observation while running on 802.11 the cpe would disconnect from AP like NV2 would before during control frame timeout disconnects?