Flexibility is paramount in any Wireless network. We all want to build the minimum to meet the coverage and performance expectations for today and tomorrow. The problem is what about day after tomorrow? Once wireless kindles in minor uses and innovation begins then the usage patterns start to change. Of course there are the fixed laptop cart classrooms that make user density planning easy. Ideally we would all deploy a maximum level of capacity at all locations -- if money were no object. This is, in my opinion, the most outstanding feature and benefit that Meru delivers above all others in the a/b/g and even in the n range. Where else can you paint for coverage with an access point that can handle between 128 clients. *This is a tested number with VoWLAN phones by one of their clients* Then take that paint for coverage model and deploy additional capacity on non-overlapping channels anywhere it is needed. Now you've provided the optimal formula, the minimum to operate everywhere with the minimum costs (both financial and technical) to upgrade. You don't sacrifice your tech staffs time to resurvey by changing power levels on micro or pico cells. You don't waste resources buying more access points than you need. You DO at absolute maximum deployment gain the ability to deploy EVERYWHERE in your environment the full 3 non overlapping channels of b/g or the ful 8-16 channels of a (depending on region) l thus providing the absolute maximum possible bandwidth that either standard can supply for more clients per ap than any other vendor can support. The added option of using centralized architecture with the ability to detach the dataplane of any AP from tunneled to bridged brings management and flexibility. This way when you have multi-radio ap's capable of generating more bandwidth than you have deliverable to your controllers you don't have to decentralize your controllers, you have a choice. WIth Meru when you do this you still get configuration and firmware maintenance from the central controller. The various rules of thumb out there are wise but become less critical as scaling the network becomes less of a hassle and less of a cost. Perhaps I've had too much Meru kool-aid but this is one case where there isn't too much of a good thing. The data from their variety of clients bears it out quite well. Mike - Michael G. Ruiz, ESSE ACP A+ Network and Systems Engineer Hobart and William Smith Colleges Information Technology Services P.315-781-3711 F.315-781-3409 Team Leader: Derek Lustig ([EMAIL PROTECTED]) Did you know that HWS Students, Faculty, Staff, Alums, etc can purchase computers, accessories, electronics and software at a discount through our partner CDW-G? http://www.cdwg.com/hws/ -
________________________________ From: Brooks, Stan [mailto:[EMAIL PROTECTED] Sent: Thu 6/14/2007 3:42 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Cisco vs. Meru article Kevin - I would caution against just looking at coverage for your high school deployment. I would also consider your user density. We originally went for coverage over capacity at our Law School deployment a couple of years ago. When the instructors "discovered" wireless coverage, they had their students all try opening web pages at once - 5 classrooms of about 120 students each that was covered by 4 APs. Needless to say, not all the students were able to get on, much less surf to the web pages. We use a rule of 20-30 maximum users per AP here at Emory; less if we expect any sort of multi-media traffic on the wireless network. Personally, I definitely see value of a centralized architecture for as little as 6-10 APs. The centralized systems allow for much easier configuration and management than fat APs, and it will give you a better view into your wireless network. BTW - Emory is an Aruba shop with about 1525 APs and 21 controllers. >>-> Stan Brooks - CWNA/CWSP Emory University Network Communications Division 404.727.0226 [EMAIL PROTECTED] AIM: WLANstan Yahoo!: WLANstan MSN: [EMAIL PROTECTED] -----Original Message----- From: Kevin Whitney [mailto:[EMAIL PROTECTED] Sent: Thursday, June 14, 2007 2:34 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Cisco vs. Meru article May be a little off subject but I would like to post question out there as it seems there are some happy Meru users here on this forum...... Any thoughts or advice on implementing/selecting a wireless system for use in a High School environment ? Specifically, would love any feedback on pros/cons of a central controller based system (ie -Meru, Aruba, etc) vs installing Fat AP's around our building. While our needs are quite simple I am sure, compared to the size of other user's who have posted, I can see there is a great deal of knowledge and experience in this area. Basic site surveys conducted here have indicated we need somewhere around 25 access points to provide coverage throughout our building. Appreciate any input on this subject. Kevin Whitney District Technology Coordinator Cresskill Public Schools 1 Lincoln Drive Cresskill, NJ 07626 201-541-4162 [EMAIL PROTECTED] http://www.cresskillboe.k12.nj.us <http://www.cresskillboe.k12.nj.us/> -----Original Message----- From: Dave Molta [mailto:[EMAIL PROTECTED] Sent: Thursday, June 14, 2007 12:21 PM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Cisco vs. Meru article Debbie, They were Intel 2915 clients. I have some pretty dense spreadsheets covering various permutations of clients and infrastructure if you are interested in seeing raw results. We didn't come away from this with any firm conclusions about what's good and what's bad (I guess we've learned our lesson about pointing the finger too soon!). What was most interesting to us was the fact that there was so much variation, which is something we didn't expect from such a mature standard. dm > -----Original Message----- > From: debbie fligor [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 14, 2007 11:59 AM > To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > Subject: Re: [WIRELESS-LAN] Cisco vs. Meru article > > On Jun 14, 2007, at 10:24, Dave Molta wrote: > > > Just to elaborate a bit, the article James sent around was not the > > original Meru-Cisco feature story but rather a column that > reports on > > results of subsequent testing. In this column, I reported three > > things. First, Cisco was unsuccessful in getting the Wi-Fi > Alliance to > > rescind Meru's certification. Since WFA certifies interoperability > > rather than standards compliance, this is not proof that Meru isn't > > stretching standards a bit but it still casts a cloud over Cisco's > > allegations. Second, I reported findings from subsequent > tests where > > we added Aruba to the mix and found that Cisco's performance also > > cratered when co-located with Aruba gear. > > Again, that could indicate that Aruba is also somehow > playing foul as > > well (Cisco speculated that they might be using a variation of PCF > > interframe spacing, though Aruba denied it) but it doesn't > look that > > way to me. Finally, we decided to re-run these interference > tests with > > different mixes of clients, using Atheros, Broadcom, and Intel > > chipsets. We found significant differences in the > performance results. > > Atheros-based clients performed best. > > Something I noticed in the article was that Meru did the worst with > Intel chipsets, but which chipset wasn't mentioned. > > The 3945 Intel micro code bug makes them work very poorly with Meru > and causes some problems with other vendors APs. > We've been waiting for an update from Intel, but still don't have it. > What Intel has done is ceased to sell that chipset > -- this worries me that there wont be a microcode fix, but at least we > wont have new equipment coming in with that card. > > So if the testing was with all 3945 cards, I don't think that > accurately indicates Meru doesn't work well with Intel in general. > Dave do you happen to know what the cards were? > > For those not following the problem with the 3945 cards, there is a > bug in the micro code that causes it to crash if it sees out-of-order > packets from the same AP. I heard this from an Intel employee on a > conference call with them and Meru. It had been replicated in Intel's > state-side offices and finally at their development site in Haifa last > February just days before our phone call. > > Since all Meru APs look the same to the client, it's easy for things > to be out-of-order like that. The initial work around of setting the > power save mode to off didn't work, not because it was the wrong work > around, but because the driver kept taking it out of "never power > save" mode. If you update to the latest Intel driver, and then again > set it to not use power saving, it stays set that way and the > disconnects go away, at least for the ones we've tried it on so far. > > > > > The broader issues here relate to standards compliance > (e.g., to what > > degree can a vendor selectively implement certain elements of a QoS > > standard?) and, perhaps more importantly, performance issues with > > Wi-Fi that may arise in the future as the density of > deployed networks > > results in increasing levels of co-channel interference. I am > > particuarly concerned about the intersection between private > > enterprise WLANs and public metro Wi-Fi networks. It may > not be a big > > problem today but I wonder if it will be a problem in the > future. We > > understand that our tests represent worst-case scenarios that few > > enterprises currently experience but sometimes there is value in > > pointing out the worst-case situations. > > It's always good to know what to keep an eye out for when you're > designing something. We're not seeing problems in our still Cisco > buildings that are near Meru buildings that we are aware of, and the > users are pretty good at telling us if it quits working. > > > > > If there's a silver lining here, it may be that 11n is > likely to push > > most enterprises towards more pervasive 5 GHz deployments, where > > co-channel interference is not such a big issue. > > > > dm > > > > > ----- > -debbie > Debbie Fligor, n9dn Network Engineer, CITES, Univ. of Il > email: [EMAIL PROTECTED] <http://www.uiuc.edu/ph/www/fligor> > "My turn." -River > > ********** > Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at > http://www.educause.edu/groups/. > ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
