I have been battling with the Nstreme poll timeout issue for over a year now. I have read numerous posts on this issue and tried all suggested fixes but nothing has worked 100%, not to say that this is a 100% fix but so far so good. I have over 90 SXT Lite 5's connected across 9 SXT SA's. All are using Nstreme because NV2 over multiple hops is just horrible no matter how you configure it. I have about 5 SXT's that constantly disconnect and reconnected with "not polled for too long" errors in the log. Changing channels sometimes fixes the problem but not for long. After changing channels, the issue may occur once every 2 hours instead on once every 50 minutes. The ONE thing I found that stopped this from happening was to disable PERIODIC CALIBRATION! A link that could only manage 2 hours has now been solid for 16 hours. I did also drop AMSDU limit/threshold to "0" but I am not sure if that made any difference. For me, AMSDU at "0" also smoothed out throughput fluctuation during high load.

Interesting and good to know; I will file that one away.

Back when we were doing a lot more Nstreme and MT wireless clients/CPEs, when we were using Atheros 5413/5414 based b/g cards, our experience was that increasing the "hardware retries" value on the base station/AP from its default (either 4 or 7, depending on the firmware version) to something much more north of that (12-15) would solve this issue 9 out of 10 times.

We pretty much stopped using multipoint Nstreme (or NV2 for that matter) right around the time that 11n chipsets became the norm, so I don't know if this trick still helps with more modern hardware and software or not.

-- Nathan

I tried hardware retries at 15 on both sides but it did not completely fix the issue. With periodic calibration off and hardware retries at default, the problem has vanished. I have a CPE in a very noisy environment that was running NV2 until a few hours ago when I switch that segment to nstreme and above settings. The connection has been solid for 4 hours now. This particular link would not stay up for more than 10 minutes forcing me to use NV2. Not only is it solid but the throughput is almost double what it was. It seems to me that nstreme has some kind of problem with periodic calibration. Maybe Mikrotik support can comment on this. The only problem I have is that the new wireless driver which is the only driver available on the new ac gear does not have this setting.

Interesting and good to know; I will file that one away.

Back when we were doing a lot more Nstreme and MT wireless clients/CPEs, when we were using Atheros 5413/5414 based b/g cards, our experience was that increasing the "hardware retries" value on the base station/AP from its default (either 4 or 7, depending on the firmware version) to something much more north of that (12-15) would solve this issue 9 out of 10 times.

We pretty much stopped using multipoint Nstreme (or NV2 for that matter) right around the time that 11n chipsets became the norm, so I don't know if this trick still helps with more modern hardware and software or not.

-- Nathan

just curious, what do you use now?

just curious, what do you use now?

I should clarify that we didn't rip out the Nstreme stuff. There is still a fair amount of that in use. Most new installations, though have been Ubiquiti Airmax M5. It ain't perfect either, though, and certainly has its own share of problems.

-- Nathan

just curious, what do you use now?

I should clarify that we didn't rip out the Nstreme stuff. There is still a fair amount of that in use. Most new installations, though have been Ubiquiti Airmax M5. It ain't perfect either, though, and certainly has its own share of problems.

-- Nathan

I moved away from the Airmax stuff when I realized that multiple hops dropped the speed considerably. I also see the exact same issue with NV2, bot are TDMA based. Nstreme is so much faster over multiple hops probably due to lower ping times and jitter but I don't understand why it is so unstable. It's a shame really. I can also confirm that disabling periodic calibration is not perfect. I just had my first experimental link drop since I started this topic. Still, it is much much better than before.

Sounds interesting if it is even some sort of fix for this problem, but I can't even try it, all my links use wireless-fp now.

I can't find this setting on wireless-fp
I'm having better performances using nstreme than using nv2 in 5GHz-AC, but nstreme disconnections are annoying!

Orangetek,
where you did find PERIODIC CALIBRATION ?

Guys from Mikrotik, please!!!!

We have here 2 big problems, one of them is not solved for years (Nstreme - not polled for too long)!

Second problem is nv2 over multiple hops. It is unusable for higher bandwidths over single TCP connection and also because very high latency. Please, try to replicate this (not in your lab, but outside during real conditions). Try to do 3 - 5 hops with nv2 and then test the max. throughput over 1 single TCP connection.

Nstreme is perfect for PtP links thanks to low latency, but when the links are randomly disconnecting, it is bad, very bad.

I wonder, how is it possible, when I use my stupid smartphone and can achieve over 100Mb on speedtest.net during driving my car on LTE network. And over PtP nv2 links, it is horrible.

I really want to know how and where Mikrotik team is doing wireless tests
Yep nv2 on AC is horrible - ok ok there are still some problems to be fix, on N is kind a slower than nstreme
only tests done in lab are good

Orangetek tnx for advice believe me I have tried everything but periodic calibration=disable never
Ill give a try, inform u soon.

zyzelis and gius64 periodic calibration option (I dont know why) in wireless-fp is removed

At first turning off recalibrate worked, but over time it got just as bad.... not a fix here...

This is very weird, still no single word from Mikrotik. I was now forced to go back to nv2, because of nstreme disconnecting.
With nstreme I was able to deliver through 5 hops(20km together) more than 100Mb through one single TCP connection with 1-3ms ping.
Now with nv2 I can get max 4Mbit.....
Sorry for my speach, but this is pure shit!!!

I too am trying to fix this issue.... again, still....

What I like best is this... Using nstreme and running a bandwidth test, I was testing if I limit the speeds so the processor on the RB was at 75% or less ( Busy CPU might cause timeout was my theory) as this is going on and the wireless disconnects, then reconnects, the limit that I put on no longer applies, it goes to the full speed capable over the wireless. This is because I don't click stop on the bandwidth test, I just leave it, since the wireless will reconnect.

BUT.. why does the limit of 75M on my receive bps no longer honored? MT? hey, this is a bug!

Note: my link drops every minute when at full speeds tests. when limited to 75M I can get it about 5 minutes connected time.
This link is a ptp using Netmetal5's.
I wish I could adjust the Polling time out value....

I am so thankful that this is a link to my brothers house for data backup purposes, but the server fails on the backup because there is no link for that duration of time to the NAS, so it really is an issue, or I can use NV2 and get less then half the speeds and longer ping and jitter issues. Disabling polling in nstreme brings the speeds down to the speeds of NV2.
Lost....