I see where you are getting at, but it isn't really relevant, at least 
the way I have my network setup.   None of my customers have an upload 
that gets to even 40% (I don't do symmetrical upload, so the highest 
upload we offer is 2meg) and the access points handle it pretty easily 
at that rate. 

If you are offering a symmetrical service, then I will concede that 
polling is an important consideration.   It is pretty easy to work 
around it if you are not offering symmetrical service, however.

Matt Larsen
vistabeam.com


Travis Johnson wrote:
> Matt,
>
> Having 90-100 subs on an AP that supports roughly 20Mbps of bandwidth 
> is different than an AP that supports 5Mbps with 128 subs. There is a 
> reason Trango, Canopy, Alvarion, and many others do a "polling" 
> system... it allows better, more effecient use of the available 
> bandwidth... especially for providers like me that sell a symmetrical 
> service (1meg x 1meg, 2meg x 2meg, etc.). So the upload is just as 
> important as the download.
>
> Here's a test for you... take an AP without polling and start an 
> upload on a client that is 80% of the capacity of the AP and then try 
> and surf with another connected client and see how it "feels"... if 
> it's even possible. With the Trango AP's, we are able to use 95% of 
> the rated bandwidth on each AP before we see any issues (jitter, 
> latency, etc.). That just is not possible with a non-polling system 
> (in upload or download scenarios).
>
> Travis
>
>
> Matt Larsen - Lists wrote:
>> 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/
>>
>>
>>   
> ------------------------------------------------------------------------
>
>
>
> --------------------------------------------------------------------------------
> 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/



--------------------------------------------------------------------------------
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/

Reply via email to