Polling protocol

[encom]

Hello,

is it possible to implement a polling protocol for NS5 ? Something like polling in OSWave or mikrotik Nstreme. Thanks

[tjohnson]

Hello? Any response from UBNT on this?

[marceloru]

as a product designed for WISPs, it would be important to implement a polling method owner or license an existing one .. as nstream or oswave

[corky]

mt recently improved nstreme so that it produces sometimes spectacular results on p2mp links now. In the past, I would have said it was not important to implement, but now it is.

Corky

[kijoma]

hi,

what have they done to improve it?, we stopped using it due to crap latency generally and poor throughput under less than perfect signal conditions.

Plus i doubt MT will let UBNT use their protocol so as we are now using more UBNT kit for new builds than MT it makes sense for us not to use nstreme and as with all proprietary systems they have to be taken up wholesale or not at all.

[tjohnson]

http://forum.mikrotik.com/viewtopic.php?f=7&t=27302

[corky]

As you can see from tjohnson's link, MT is never very forthcoming about how their stuff works. I happen to know Butch Evans well though, and he knows the owner of MT so he tends to understand what is in their mind better than most. He has also just been working with their stuff as a consultant from the beginning.

He told me that NStream was mainly designed for p2p links originally. I have found over several years that it does at times produce wonderful results (2x throughput, more stable jitter) on p2p links, and at other times it just does not matter much. I have no idea why the variability. I have also found that it is harmful to p2mp links, it degrades throughput by about 50% typically.

Butch told me about the new tower side algorithm and I tried it on a 900mhz tower in a noisy location that has always had crummy performance, with ping times averaging around 160ms, and lots of variability in the 60 - 800 ms range. I had tried all the usual stuff to improve this with no luck at all.

After installing the new polling package on the tower (no client change) pings are 21/avg 8/min 161/max (looking right now). This has been stable for about 3 weeks. This did not have any real effect on throughput.

Unfortunately the 900 towers are my only pure MT towers, so I can't really test on other towers, but I now wish I could. It would be a nice tool to have available.

Corky

[taylorc]

Well, if no one will give us the interoperability we need, then perhaps it is time to bring the GPL hammer down on OSWave, Mikrotik, etc demanding the code modifications they have made to open source software.

I'm so sick of all these companies producing proprietary software from open source systems and then locking us to their platforms.

I don't care if companies use open source software... I don't even care if they keep their changes secret and proprietary. But what I DO care about is when they take something from the GPL and then use it to PREVENT the interoperability of their innovations with the innovations of others.

[WHT]

time to bring the GPL hammer down That shouldn't be too difficult. Look how M$ bashed when Sun took them to court after messing with Sun's JAVA by making building it with extension that would only work in IE.

[tomekmak]

There is one reason why i don't use NS as mass CPE - no pooling.
I have to use MT :-(

[kijoma]

hi,

Up until recently at least, Nstreme wasn't much good at PtmP, as declared by their own people on the forums, it was a "point to point" aimed feature which to me means polling was pointless! as polling is for multiple users to get around hidden term/collisions etc..

We just removed all our nstreme links, latency has improved considerably and throughput is not much different (look up high latency and throughput issues on google to see why).

To me a polling protocol in its basic form replaces the CSMA send/ack method with an AP controlled "stateless" send/nak system (dont ack what you get, nack what you didn't get on a per block basis). And it needs to be an open standard!

extras like large frames should be options, not forced.

[tomekmak]

Dude, try to put NS5 as basestation, then connect 20 NS5 with different distances 0.5-3km and you see what can happend when each of them start generating 1Mbps traffic... 5k ping, packetloss etc etc.

Then do this on MT's with pooling enabled.

Hard to say that but NS5 w/o pooling protocol is another indoor cheap and poor device...

[kijoma]

hi,

we have MT/tranzeo/UBNT without polling and customers between 1km and 20km from the aerial and pings are fine. the key is to manage bandwidth at the main server.

this is on 5ghz and if you have problems with 20 802.11 clients then you need to look at your network config somewhere.

the NS radios are no different than the MT RB1xx range as far as technology goes but you get much more for your money, you get a product!

[tomekmak]

atm i sold almost whole NS5, cause of instability and no pooling.
I got more than 500 cpes on MT with pooling and nsteme enabled, and for sure - atm NS5 is not comparable with MT.

Especially when on MT i can put 20Mbits FDX for each iface with nstreme & pooling protocol (around 20 cpe's / for each) w/o any problem.

I was tested NS5 as basestation, with 10 NS5 as client (different contracts 0.5-4Mbit) and what i can say - total failure.

I'm Sorry,but without pooling NS5 is incomplete product.

[kijoma]

hi,

perhaps you would feel happier on the MT forums then?

we will continue to use what works for a specific requirement and UBNT fits a big part of this now that MT really had no "product" to fit.

the RIC/522 is the only "product" they have, everything else is kit form which is great for bespoke AP's, multi radio etc.. (except since the damn triple shot became standard!!). we have plenty of MT kit in service like that but an NS5 costs similar to an RB (minus radio, box,aerial) and the ones we have in service are all working real well with excellent CCQ and throughput!

We provide up to 13 Mbps to end customers via them and they can get it. nuff said

When the routerstation comes out the purpose of MT takes a bigger dive here.

The way they treat their customers/consultants is pretty disgusting too.

[tomekmak]

That's why im posting there. I would love to use NS5 cause of all-in-one solution. No need to make own CPE, faster mounting, unique design and of course - price.

i need just pooling....

[rconaway]

If you really need a polling protocol, SkyPilot announced today that for $99 you can upgrade any of the 5 products to syncmesh. However, you still need a SkyPilot Gateway or Extender to talk to.

[laser3]

Skypilot has an excellent solution but an awful price compared to UBNT, and that why UBNT is my hardware of choice.

[WHT]

That's one of those 6 of one, baker's dozen of the other. OK, poor analogy.

I'd rather spend $2,500 once on a NetEqualizer with virtual polling, than a $200 (SkyPilot price?) per client over and over again.

(200 NS x $90) = $2,500 = $20,500
(200 SP X $200) = $40,000

[rconaway]

I'm certainly not opening a debate on pricing. Just pointing out a piece of information. Both systems have applications that are unique to their product market. SkyPilot has a very good 4.9GHz solution and long range mesh solution. I have deployed a lot of both products and right now in the 5.8GHz band, I get the best of both worlds. When SkyPilot releases a less expensive 5.8GHz Gateway product, that will make it a tougher decision on what to deploy.

If you need polling however, you have SkyPilot, Motorola, and a few others. SkyPilot is expandable in a mesh environment very easily and with the new pricing and firmware options, a little more flexible. The tradeoff is bandwidth and cost.

There isn't a comparison on initial cost but SkyPilot's firmware is more mature and easier to manage. You have to balance that against the time it takes to configure, deploy, and then manage real-time if you are comparing their 5.8GHz solutions. Simultaenously, SkyPilot is already certified for 5.4GHz where Ubiquiti is not. Many things to consider other than price. Support has a cost to it and your labor has value. SkyPilot scales up easier than AirOS at this point. Mesh systems are easier to deploy for field techs. I have 2 wide-area SkyPilot networks that I look at about every 3 months if that. They are rock solid at this stage of their firmware. I'm sure AirOS will get there also.

[randy]

Regarding NetEqualizer - if you simply need traffic shaping (to sell tiered services or rate-limit users), then a traffic shaper like NetEqualizer should work. But SkyPilot's protocol is more along the lines of MAC layer enhancements to avoid 802.11 CSMA/CA issues in outdoor wireless (in addition to features like traffic shaping, multi-hop relay, antenna switching, management, ...)

[rconaway]

If you need traffic shaping at a much lower price, then get Patronsoft FirstSpot. That allows bandwdith utilization per user. If you need more granular than that, look at something like an Enterasys switch which allows traffic shaping per port address. Still a lot cheaper than netequalizer but it may not be as user friendly.

[WHT]

As Randy pointed out,

Firmware to upgrade NS5/PS5/Loco5/Bullet5 to SkyPilot SyncMesh is available now: http://www.skypilot.com/newsevents/pr/pr_2008_12_10.php

Each device needs a $99 key.

[WHT]

rconaway...

If the key for the Loco 5 is only $99, I'd jump all over it and go with SkyPilot then. The Loco 5 is really overkill for us, so we never need anything as powerful as the NS, much less the PS.

R...let me get back to ya on this via email.

[rconaway]

I agree depending on the application and budget. I still have proposals out there that are SkyPilot because it's a carrier class product that requires very little technical support time.

[kijoma]

If you need traffic shaping at a much lower price, then get Patronsoft FirstSpot. That allows bandwdith utilization per user. If you need more granular than that, look at something like an Enterasys switch which allows traffic shaping per port address. Still a lot cheaper than netequalizer but it may not be as user friendly.


surely a cheap way to manage BW (assuming its not broken in the current FW!) is to use a MT routerboard at the AP end and use MT *linux* qos qeueing.

[rconaway]

No doubt but keep in mind that we have several people that do tech support, some of them non-technical, that need to be able to check billing, account status, passwords, etc... In our case, FirstSpot handles all that in one windows program. (Full disclosure - we are a U.S. based dealer).

One of the things that doesn't get differentiated here is the difference between government or enterprise deployments and smaller self-supported installations. In the enterprise environment, sometimes we turn over the support to other staff. In those environments, AirOS doesn't quite cut it if it costs $500,000 to deploy it. They want to see professional management tools. As cool as Dude is, and we use it everywhere, the guys supporting the system sometimes barely have any computer experience which makes Dude a non-starter. If it breaks, they power cycle or replace. That's it. When that doesn't work, we get called.

Governments also don't let you skirt the rules. For example, if a link doesn't work well, you find a way to fix it within FCC rules rather than bending them a little. There is always some government employee or other vendor looking to find dirt on you.

Governments assume that wireless works as well as wired. That is why they want 10 engineering studies before putting up an equipment and why they have a hard time believing that an $80 radio works as well as the $5000 radios they were using. From a hardware standpoint, I agree. From a firmware standpoint, AirOS is close but not quite there yet. It either needs mesh or that "Area" feature that has been discussed (in my humble opinion). That doesn't mean I wouldn't deploy it in that environment, it just has to thought through from design to support to operation. For the record, I have proposed 100% Ubiquti designs in government installations already. However, these are fixed environments where we install and they only exchange.

[rconaway]

One more point on maturity of firmware. We need AP's to run WDS and AES. However, if we do that, WDS breaks. I haven't tried 3.2.3rc which I'm doing today but that is a good example.

[encom]

Hello,

i know that you are doing great job guys but please could you post here your statement regarding the polling ? Are you even thinking aobut this feature for NS ? Thank you

[kijoma]

One more point on maturity of firmware. We need AP's to run WDS and AES. However, if we do that, WDS breaks. I haven't tried 3.2.3rc which I'm doing today but that is a good example.

I am sure they could make it "work", then they can be flooded as MT forums are with people moaning about "key exchange timeout" errors and the like that come from AP-AP WDS with WPA.

I would love it to be implemented but not if it isn't as stable as not having WPA.

[rconaway]

I think they should run a Mesh Firmware Challenge like the RouterStation challenge

[kijoma]

hi,

problem is... Mesh is one of those technologies that looks so good on paper but in reality isn't..

Have taken down a few mesh networks of the locustworld variety, not good..

[rconaway]

There are places it works great. I have several of them up and no complaints. The advantage of mesh is that an AP will connect and route automatically without user intervention. That is a huge advantage to clients in a dynamic environment like police, fire, security, etc... I have 5 projects I'm quoting now that have that need. I'm looking at auto WDS for some of those to keep the costs down. Others are looking at SkyPilot because of the need.

[kijoma]

hi,

agree in those applications where availability is required without any throughput promises or SLA.

for domestic/business fixed access there is no real way in a mesh you can provide a consistent high throughput due to its chaotic nature.

[rconaway]

Actually, that's not really true. In fact, with properly designed mesh, I would argue that it's the only way you can. However, that's dependent on the implementation of the capabilities of the mesh.

A fully-automated mesh system will dynamically route all traffic based not only on signal strength/modulation, but will also route based on load. If there are multiple paths for traffic, mesh systems will balance that load to make sure every packet makes the fastest and shortest trip to the ingress/egress point.

However, not every vendor implements that level of mesh. Some vendors simply route based on signal strength/modulation. Given that however, good administrators then analyze the network and can define a preferred parent path regardless of modulation rate. The mesh will prioritize a parent path. We do that with one mesh vendor because we are feeding areas that have different numbers of cameras.

Therefore, if the mesh vendor supports dynamic load balancing, the I believe that it was always be more efficient and will respond faster to changing loads than manually setting up a network. There are also vendors that can theoretically dynamically change power output to each user per packet avoid interfering with lower power connections. This however, requires more cpu power than most vendors implemented and hasn't worked as well in reality yet but it's an interesting idea.

I will tell you that I tested a Tropos 2.4GHz radio with dual 6dBi antennas against a Vivato AP with wave-guide sector antenna that once hit a laptop at 1.2 miles. 6' off the ground, the waveguide and the Tropos both hit a laptop at 1200' with the user behind a building and both dropped the user a few feet after that. That made a believer out of me that some of the higher-end mesh equipment is pretty good. If 2 6dBi omni antennas on a Tropos can do what a securawave sector antenna could do, the receiver section must be pretty impressive, Yes I know that some of them also use Ubiquiti cards in them but this was a very interesting piece of information.

[kijoma]

A fully-automated mesh system will dynamically route all traffic based not only on signal strength/modulation, but will also route based on load. If there are multiple paths for traffic, mesh systems will balance that load to make sure every packet makes the fastest and shortest trip to the ingress/egress point.

in reality they are all transmitting on the same frequency, CSMA will mean all the purported advantage of taking the shortest route is lost with multiple repeats and of course the throughput halving per hop. stick blind terminal clients on it and things get so much worse...

If you can point to a successful high bandwidth mesh using 802.11, in the UK especially then please do.. the only purported advantage is multi path resilience, again this only happens if lots of nodes can see each other.

When they can of course then the throughput is screwed as if any of them are talking the rest have to wait to talk ..., if a line of them are talking then the situation exponentially goes bad..

Mesh has its uses, the string of failed mesh systems in the uk for broadband provision show it is not something you take on blindly, there will be a lot of cost and a lot of infrastructure radios.

Not long removed a 14 node mesh that covered about half a small village over here and replaced it with an independently back hauled three relay PTMP system and now the whole village is covered and a load of roof top omni sticks disappeared to be replaced with asthetically placed NS5's etc..

the cost of the mesh was many multiples of what replaced it and now people can enjoy throughputs of over 13 Mbps compared to less than 1 Mbps before (depending on where they were on the mesh).

The village in question has a lot of dense tree cover and it certainly is not flat . This didn't stop a discrete 5ghz network though well out performing a 2.4ghz mesh though.

Sorry, not sold on mesh here yet :wink:

[rconaway]

You are describing single radio mesh systems. Multi-radio mesh will deliver as much as 35Mbps to any node. We work with several mesh radios that can do the following:

1) Connect 360 degrees and 4.9GHz at distances up 10 miles
2) Provide 35Mbps in any direction (backhaul) with no bandwdith loss per hop
3) Provide full 30fps to a vehicle moving 45 mph with no frame loss.
4) Support 8-16 SSIDS, VLAN support, QOS, traffic prioritization, 256-bit AES encryption, load-balancing, etc....

These are highlights from 4 different mesh vendors. These are things you cannot do with a PTMP system. Yes, you pay a boatload for those features which is typically the cost of developing your own firmware from scratch, getting FCC certifications, etc.... It's up to the Integrator to decide what the customers needs are and to provide the best product for those needs. A lot of my municipality projects involve some sort of mobility and multiple SSIDS. Those issues alone may preclude a full Ubiquiti.

I'm not pushing mesh, just trying to get you to understand that there are applications for all sorts of hardware. I just spent 9 hours on a lift today setting up 15 Nanostations on a tower so I understand your philosphy. This system along with another building that will be full of Nano5's and Bullet2 HP's will be supporting about 300 users (currently 220) over the next 2 months.

[WHT]

they can be flooded as MT forums are with people moaning
But wouldn't that get them banned from the MT forums? HAHAHAHAHAHA

Inside joke, sorta.....

[Blizz]

a feature to enable/disable CSMA & pooling like what MT did could help in some noisy situation, I guess that doesnt really need very similar/exactly compatible to proprietary MT nstream.

[brasileottanta]

I don't understand , why don't consider the implementation of hiperlan/2 protocol ?

Hiperlan/2 solve all problems . TDMA/TDD , same PHY of 802.11 , best performance in NLOS . Actually , in the world , only Alvarion have implemented this , with brezeeaccess VL line products.