|
Matt, Yes, we are offering symmetrical speeds (1meg x 1meg, etc.), so our testing was based on that. So I would agree if you were not doing that, you can probably get 75 users (at a very maximum) on an 802.11 AP. However, I still believe there are other issues with plain 802.11 that does not have any type of polling... such as having a customer with a -50 signal while everyone else has a -75 signal. Regardless of QoS or any other setting, that -50 customer is going to get priority over anyone else on that AP. I would be curious what happens on an AP if that one customer were to start a very high pps upload using all of their allocated bandwidth? All of our tests used the AP as the bandwidth controller. There were still substantial issues when a customer started an upload. Here's where the numbers get interesting.... a StarOS AP is $300, but I can do a Canopy AP for $600 (and I can put the same antenna on it that you are putting on the StarOS system, and we can both be in violation of the FCC guidelines)... but I can put up to 200 customers with no impact on latency. So even if we figure 100 customers on the Canopy AP, it's the same cost as the StarOS AP. And for us, the bigger issue was being able to co-locate many AP's on the same tower. With Canopy, I could technically put 24 AP's on the same tower (even right on top of each other) and everything would still work. ;) As for management, we wrote two PHP scripts (total time of about 2-3 hours) that provide full management of all our Canopy AP's and SM's. We use JFFNMS to gather all the stats automatically (we don't have to add each SM, we only add the AP one time and it grabs everything about every SM connected including packets, traffic, signal, jitter, etc). All of this is open source, and I will probably post the scripts sometime in the near future. So now anyone with proper access can do any support or maintenance necessary all from a web browser... no PuTTy or whatever that crazy stuff is that StarOS requires... ;) Travis Microserv Matt Larsen - Lists wrote: Preparing to launch the Holy War Hand Grenade.....:^) On the AF09 wireless, I am just following the terms you gave me as a "typical example of 802.11 not scaling". If there is only one access point for 50 users, then yes - cap it at 1Mbps. How much do temporary users need? If they needed 10meg, I would have deployed three 802.11b/g APs on different channels with different ESSIDs, and an 802.11a AP. A single X4000 board with StarOS and four omni antennas would have handled that just fine while delivering 5meg or so per client. But your real world example was a single AP. If someone wants to bottleneck a 300Mbps link with a single AP and then point out how bad that single AP performs, that is just bad network design and you can't hold 802.11 to blame for the problem.As far as polling goes, it just has not proven to be necessary to provide a quality level of service in many cases, including 99.9% of my customers. Note that I did not say ALL cases, as there are situations where polling does make sense - especially when you get beyond the 50-75 user per sector mark. I just haven't had any use for it because the extra costs of deployment did not justify the minimal benefits since nearly all of my APs are below the 50-75 users per sector range. I am familiar with the testing that you did with the 802.11 gear, but something just doesn't add up in your results, because my results are way different. Not knowing details, I'm going to make the assumption that you were using symmetrical bandwidth profiles (1meg up/1meg down), full speed with no bursting, and that your bandwidth control was being done at some point behind the access point. To get a higher number of users on an 802.11 AP, the upload rates need to be limited. The key is picking the tradeoff that works best. With symmetrical speeds and multimegabit packages, 20-30 users per AP is probably all you are going to get. With asymmetrical bandwidth packages, the available duty cycles for delivering data to customers are maximized and the latency issues you mentioned are mimimized. Bursting is another key feature to have available on 802.11 networks, since it gets the short data requests delivered faster. Bursting enabled us to double the number of users on an AP without issues. Having the bandwidth control on the AP, and not a device somewhere behind it - also seems to help considerably, and minimizes the chances of issues coming up between the wireless link and the bandwidth controller. In my tests, I can start simultaneous uploads or downloads on multiple CPE units on a loaded AP and still maintain decent latency (jumps from 2ms to 20-25ms) with no packet loss. YMMV, but that is what I see on my system, deployed in this manner. I'm glad that Canopy works for you and the others that use it. I have no use for it whatsoever because the 802.11 gear does what it needs to do when deployed in this fashion. When I have customers that need to make the move beyond what our system is capable of, I'm going to spend the money on 3.65 WiMax gear. Even without a promo, I could put up 24 sectors of StarOS for less than $300 each. Or I could deploy 12 sectors and 12 backhauls. Or I could deploy 12 sectors, 12 backhauls and 3 full duplex links. And that includes real, external antennas and not the little crappy patch antennas inside of the Canopy case. And I have open source tools to manage it, not this BAM or PRIZM or whatever crazy stuff that Canopy requires. Your turn. :^) Matt Larsen vistabeam.com Travis Johnson wrote: |
-------------------------------------------------------------------------------- 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/
