I keep on getting this log entry on a very important back haul link. The setup is as follows. A 31db horizontal grid pointing to a 27db horizontal on the other side. The signal is -49/-50 over a distance of 8km and the CCQ is nothing worse than 96% but still the connection drops. Any ideas?
I keep getting the same messages on my important backhaul links. Session will DROP completely for no apparent reason, then re-associate. Log says “disconnected, too many poll timeouts”.
I’ve also confirmed this is not fixed in 5.17 test OS
What is your signal? We fixed this by doing the following. Band 5 GHz-A/N, channel width 20/40 Mhz HT Above and wireless protocol nv2 on the Ap bridge and nv2 nstreme 802.11. Where we use to only get 20 meg out we get 110 now and the CCQ is 100/100 with the backbone not having dropped once since.
We then tried implementing this through out the network and realised that the signal has to be at least -60/-60 for this to work effectively.
signal is -64/-64, and it only happens when using Nstreme. I can’t take the latency and jitter with NV2, it adds up quite a bit after 6 PtP links. With Nstreme I get ~10ms pings, if I enable NV2 on all the links, it rockets up to 40-60ms!
I’ve been battling the same issue for quite some time myself on several PTP links! Sometimes I have luck change the hw retries up to 10, but it’s a crap shoot. Getting anything useful out of the debug logs is a futile effort. It seems to be a problem for a lot of people, but there is never any real answer or fix.
anyone know if Mikrotik fixed this in 5.19? nothing on the changelog about it.. when I email they just recommend using NV2, but I can’t with this situation. Low latency is KEY
still “disconnected, too many poll timeouts”. in 5.19 but try it
I cant say all my nstreme links have this problem but 80% are disconnecting/reconnecting
and about downgrade to 4.17 on SXT or aether new products “its not supported”
Really? Yes, I’ve tried EVERYTHING. All was fine on 4.17. The problem is the newer firmware. Signals are great, noise floor is ZERO. This is a remote area and NOTHING is being used on the 5ghz spectrum. As we went up in firmwares, NV2 got better, while Nstreme got worse..
When you say “EVERYTHING” does this include RF shielding of AP + PTP’s also moving devices further apart if they are positioned close to each other, sometimes we blame upgrades + firmware when a underlining issue was always present but did not surface till upgrades + firmware or wireless protocol is changed (NV2 from 802.11)
I’ve been deploying Mikrotik PtP links for 7 years now, this is nothing new to me. There are no AP’s on these towers, only PtP links and they are completely noise free. 3.5’ 34dbi dishes each link is about 40 miles on each end, BUT why would I waste time going out and trying to move them further apart, shielding, etc when the problems go away after downgrading firmware?
I appreciate your advice, but like I say its obvious firmware related issue if the problems go away when downgrading back to 4.17.
For me I wanted to use NV2 and after a period of “control frame timeouts” http://forum.mikrotik.com/t/radio-card-rx-bandwidth/45267/1
I had to modify my AP’s + PTP’s and their positioning on a mast, after a lot of effort I now have “rock-solid” stabilty on my 100% MT network using NV2 but (there always a but ?) latency is high with NV2 and in the future if NV2 does not improve the latency I will have to consider other options for backhaul and select AP’s using 802.11 for VOIP, etc.
I have similar situation. I’d like to try downgrading to 4.17 to see how it affects the link, but I’m not sure if I won’t loose conectivity to remote site? I do have to reach other end physicaly, don’t I?
i know its 2 years old this post.. but i have exactly (STILL) the same problems on a 126km long link and i have to put one more part to the equation, why we cant use NV2… if i run this link on NV2 it gets rock solid no drops for days but apart of the 40 to 60 ms delay (which you cant use for Voip) we get a maximum of 10 Mbps troughput! but when using Nstream we get 50 Mbps (real IP trafic), but those dops of the link happens every few hours and we really tryied allready everything to fix that and it has to be a software issue, and another strange thing Nstream does: on the statistics the Tx or Rx rate seams to be droping to 6Mbps for a milisecond, which we actually figuered (after days of searching and waisting time!) is a false reading because the real stream doesnt drop