Okay all; i posted on this once before - some success at getting Nstreme to work stable over N links - now i've hit the mother load and im 100% confident of my results.

One caveat before we start - you MUST have an exceptionally good wireless link. That is to say your signal must be acceptable for the distance and if you are already running NV2 - you should be sitting in the 100% range on your CCQ's. Much less than this and you will actually go backwards with what i'm suggesting. So if you have a questionable wireless link, DONT DO THIS!

Right - its simple. You can have your choice of 20mhz, 40mhz above or below; single chain, two chains. You MUST be running at least RouterOS 6.7 (this is my test bed), the latest routerboot and have Mikrotik N cards. I can't speak for results on any other card - this is a Mikrotik forum and we are a Mikrotik house

Most settings should remain bog standard; except:

HT AMSDU Limit = 3839
HT AMSDU Threshold = 3839

Nstreme Enabled
Enable Polling
Framer Policy = Best Fit
Framer Limit = 4000

So long as you understand Mikrotiks other wireless settings you should have no trouble replicating my results. I have two links (both under 10km) running this set up at the moment absolutely perfectly - and i even get better results out of the links than i had on NV2. I am yet to try it on longer links, but thats coming and no i haven't tweaked the settings much more than you see above to try and get better performance....its on the list of things to do.

So for all of you out there running NV2 networks; give this a try on atleast one nearby link - you wont be disappointed!

Good luck

I have pretty good knowledge of all wireless parameters, but I have never changed HT AMSDU from the default setting. What exactly changes when you play with this ?

From the Wiki:

t-amsdu-limit (integer [0..8192]; Default: 8192)

Max AMSDU that device is allowed to prepare when negotiated. AMSDU aggregation may significantly increase throughput especially for small frames, but may increase latency in case of packet loss due to retransmission of aggregated frame. Sending and receiving AMSDUs will also increase CPU usage.


ht-amsdu-threshold (integer [0..8192]; Default: 8192)

Max frame size to allow including in AMSDU.

--

Historically Mikrotik users have had trouble making nstreme work with N (there are plenty of threads on it here). It occurred to me that there was potential for the two settings above to wreak havoc with Nstreme's framer size setting (if it were being listned too while nstreme was enabled). Changing those two settings to be below your nstreme framer size; for whatever reason appears to allow nstreme to run stable and perform well.

Mikrotik Guru's can feel free to comment on the specifics.

Hi,

How has it went? Still stable nstreme link?

Hi,

its an interesting topic, I like the nstreme low latency very much but wasnt able to successfully use it on 802.11n dual chain links, even some 40MHz single chains...

I have tried your setup on a 400m dual chain 40MHz link which is 100% CCQ and pushing 200Mbps with NV2 running ROS 6.15 and standard wireless package, avg latency is 3ms. When used your settings and switched to nstreme, avg latency went down to 0ms which is very nice. The link seems to be working fine even I see a bit lower troughput (around 180Mbps), which would be OK for me but when I leave the Btest running for a while and the link is on max throughput it suddenly disconnects with: This is happening only when the link is maxed out, it seems that with running 70% of maximum throughput is stable but the latency is similar or maybe even a little higher than with NV2. Also with 90% load latency goes to 12ms which is a lot higher than NV2.

With NV2 I have maximum of 220Mbps real TCP throughput and 5ms average latency with full load. I guess I will stick with NV2

Anyway thanks for the suggestion

EDIT: I gave it another chance and realized that on the client I have to set the nstreme options via terminal as its not possible with WinBox.... not sure if it makes any real difference but it looks like it does. So it make sense to me to go with nstreme on some links where there is more NV2 hops which is apparently causing low single TCP connection throughput.

So once again, thank you for a helpful topic