Travis, I've got 802.11a APs with 90-100 subs on them without polling and customers are very happy. I am one of them - as I have a 4meg connection at my house that does just about anything my Trango gear would do when I was using it. Bandwidth control addresses nearly all of the issues that polling does in the implementations I have put together.
As far as the MT community being 10x the size of the StarOS Community - it's not how big it is, it is what you do with it. :^) I've had plenty of experience with both StarOS and MT, and MT just doesn't have certain features that StarOS does. StarOS has kickass Atheros drivers and a superior way of automating the provisioning and deployment. MT does have a lot of other cool features, but I don't use them so they don't mean a lot to me. FWIW, the WAR-1 version of StarOS is stripped down to the point where it fits into 4meg of memory. Probably wouldn't be hard to port it to the Nanos. Matt Larsen vistabeam.com Travis Johnson wrote: > Matt, > > Polling is a requirement for a system that will scale to larger number > of clients. I have Trango AP's that will only do 5Mbps total > bandwidth, yet we have loaded them up to their max clients (128) and > have no issues. Latency is less than 5ms to any client at any time, > and the bandwidth is smooth and consistent. > > And although I have great respect for StarOS, the Mikrotik community > is at least 10x bigger than StarOS... it would make more sense for > Ubiquiti to load Mikrotik on the Nano's... ;) > > Travis > Microserv > > > Matt Larsen - Lists wrote: >> Travis Johnson wrote: >> >>> Matt, >>> >>> I agree with almost everything you said... except the polling part. >>> Having a robust, efficient polling system is the best thing available >>> for outdoor wireless. That is one of the main reasons we are now using >>> Mikrotik is because of their Nstreme and polling system. We are >>> finding now it's not the same quality as Trango's polling, but it does >>> work. >>> >>> How else do you keep a single customer from taking down an entire AP >>> with a large upload (usually from an infection, virus, worm, etc.)? I >>> have tested this over and over and over, and every time I come back to >>> the same conclusion... you have to have a polling system to control >>> the upload, otherwise the customer with the best signal dominates the >>> AP (on the upload side). >>> >>> Here is a very simple test... set up an AP with two connected clients >>> without polling. Start an upload on one client and then try doing a >>> download or even a ping from the 2nd client. My tests show the >>> download and/or ping to be very unreliable and very sporadic. Now, if >>> you turn polling on and do the same test, everything works fine while >>> the upload is running and the 2nd client can't even tell there is an >>> upload running. >>> >> >> Um, bandwidth limiting? As long as the AP has the upload speed coming >> from the client capped to a rate slightly less than the total capacity >> of the pipe, its not a problem. I'm doing the test right now, and I >> have rock solid pings, with a little bit of jitter. >> >> >>> What we really need is the Nanostation-ROS... a Nanostation running >>> Mikrotik (even for $50 more per unit)... that would be the killer >>> CPE... I would place an order for 500 right now today. :) >>> >>> >> >> Or Nanostation-SOS - a Nano running StarOS. >> >> Matt Larsen >> vistabeam.com >> >> -------------------------------------------------------------------------------- WISPA Wants You! Join today! http://signup.wispa.org/ -------------------------------------------------------------------------------- WISPA Wireless List: wireless@wispa.org Subscribe/Unsubscribe: http://lists.wispa.org/mailman/listinfo/wireless Archives: http://lists.wispa.org/pipermail/wireless/
