Everything goes to crap, unless you've put in bandwdith management to address those conditions. The problem gets worse when Traffic becomes... Lots of small packets and/or lots of uploads. Obviously Peer-to-Peer can have those characteristics. The bigger problem is NOT fairly sharing bandwidith per sub, but instead managing based on what percentage of bandwidth his going up versus down. This can be a problem when Bandwdith mangement is Full Duplex, and Radios are Half Duplex, and its never certain whether end user traffic is gfoing to be up or down during the congestion time. Generally congestion will happen in teh upload direction more, because its common practice to assume majority of bandwidth use is in teh download direction, so most providers allocate more bandwdith for download. Therfore when there is an unsuspecting surge in upload bandwdith, the limited amount of upload capacity gets saturated sooner.
We took a two prong approach to fix. 1) We used Trango 900Mhz internal bandwidth management, to help. MIRs set to end user sold full speed, and CIR set really low (maybe 5% of MIR speed). Primary purpose was to reserve ENOUGH minimal capacity for end users to have a time slice for uploading. 2) At our first hop router, we setup Fair Weighted Queuing, so every users gets fair weight to available bandwdith. With 5.8Ghz, we did not use Bandwdith management on the trango itself. If you have good queuing, customers rarely ever notice when there is congestion. They might slow down to 100kbps now and then, but end uses really dont realize it for most applications, becaue the degragation of service rarely lasts long because oversubscription is low comparatively to most ISPs. Usually end use bandwidth tests will still reach in the 1-1.5 mbps level ranges. We run about 40-50 users per AP, selling 1mb and 2mb plans. But the key is Queuing.... If you dont have it, when congestion is reached packet loss occurs, and degregation is much more noticeable by the end user, because TCP will become way more sporatic in its self-tunning. We also learned faster speeds w/ Queuing worked much better than Limiting to slower speeds. We also learned avoid having speed plans higher than 60-70% of the radio speed, to minmiize the damage one person can do. VIDEO can quickly harm that model for the individual end user doing video, it prevents the video guy from harming all the other subs. Therefore if someone complains about speeds, its jsut teh one person that gets discruntled, not the whole subscriber base.. Tom DeReggi RapidDSL & Wireless, Inc IntAirNet- Fixed Wireless Broadband ----- Original Message ----- From: "Al Stewart" <stewa...@westcreston.ca> To: "WISPA General List" <wireless@wispa.org> Sent: Thursday, October 15, 2009 11:45 AM Subject: Re: [WISPA] Simultaneous connections > Okay, that's the ideal ratio. Which under normal casual usage > probably works great most of the time. But what happens if, say, 15 > or 20 of them are all connected and using for downloads/uploads etc > at the same time? > > Al > > ------ At 11:34 AM 10/15/2009 -0400, chris cooper wrote: ------- > >>At 500k per user I would cap users at 50 on that single AP. 35 would be >>better. >> >>Chris Cooper >>Intelliwave >> >>-----Original Message----- >>From: wireless-boun...@wispa.org [mailto:wireless-boun...@wispa.org] On >>Behalf Of Al Stewart >>Sent: Thursday, October 15, 2009 11:21 AM >>To: WISPA General List >>Subject: [WISPA] Simultaneous connections >> >>Using a 900 AP (like Trango) theoretically allows up to 3000 (3.0 >>meg) bandwidth. But there has to be a limit on how many simultaneous >>connections can go through the AP and maintain bandwidth. At what >>point -- how many using/downloading etc at the same time -- would the >>bandwidth be reduced by usage to below 500 (.5 meg) or lower? There >>has to, logically, be some kind of limit to what the pipe will hande. >> >>We're trying to evaluate our user to AP ratio in real life. >> >>Al >> >> >> >>------------------------------------------------------------------------ >>-------- >>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/ > -------------- END QUOTE --------------------- > --------------------- > Al Stewart > stewa...@westcreston.ca > --------------------- > > > > -------------------------------------------------------------------------------- > 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/
