Has latency\jitter with N-Streme in PtMP been fixed in 3.0?

not possible to test it yet because v3 on rb133c it is still not working good.
As soosn as we have a workable beta we will be able to do e field test using WMM to check is someting is going to be better

But we are sure MT doens't do miracle because it is a matter of radio chipset and not only software.

Regards

I don't know that it is a chipset limitation like many people say. There are other firmwares in the world using polling mechanisms with Atheros cards and do so quite nicely.

Any update on N-Streme in v3?

up

We just had a client on V3 RC5 lock up with Nstreme. Everything works fine for a few hours. It starts going to 100% CPU and dropping blocks of packets. Then the board just locks up and needs to be power cycled.

We've seen this problem since the beginning of the beta series and it looks like it hasn't been fixed.

we have problem also about memory leak (when some kind of traffic is passed) in ap rb532 not yet fixed.

to fix this problem, we need to know what kind of traffic it is that causes the memory leak, so we could try to reproduce it.

p2p

p2p

maybe you know what kind of p2p traffic - DirectConect, torrent,emule, etc? I think if you look into the connection tracking table you could see what kind of P2P protocol is active now.

connection tracking disabled on that ap sorry. then it is pppoe incpasulated traffic.

connection tracking disabled on that ap sorry. then it is pppoe incpasulated traffic.

could you make the support output file and send it to support@mikrotik.com

sent you the mail with two supout files the day after rc5 was out.

the ticket number is: 2007081466000609

Has anyone test this on a RB333 AP?
Thanks.

Has anyone test this on a RB333 AP?
Thanks.

we have a 333ap running rc5 with a xr5, the idea was to feed 3 small grain legs as repeater towers from one of our larger cell towers, we had 3 clients connected for 1 day (one of the grain legs collapsed the next day, truck took out a guy wire, and the other grain leg came as part of an acquisition we did, turned out there were no customers left on it because the small town recently got DSL and the previous company had been down for 45 days, so we pulled the equipment down) durring that one day, I was able to push about 13-14mbps across the AP as a whole (data rate locked at 24) with framer policy off and the latency stayed between 1 and 4ms constantly. if I pushed any more across (only could get 1-2 mbps more) latency jumped rather high and speeds became erratic. with each connection limited to 10mbps, I could max out one and push a steady 10mbps, and ping another and see 1-2ms response times (with a occosional 15-30 here and there).

note, framer policy was off, and csma was left default for these tests. we are holding off on any further csma testing until we get a v3.0rcX build that we can get to keep radio links stable for more then a few hours...

*bump*