Kevin, Regarding feedback on Aruba, I can tell you this:
We been extremely happy with Aruba's solution which has allowed us to load balanced users with easy, manage our WLAN from one GUI, and config changes are a snap. We had a think AP (Proxim) deployment of 150 AP's and had major issues with the classroom environment. Every time there was a test with 40-50 students there was always complaints afterwords with connectivity and thoroughtput issues. Our deployment stratagie now is based more on user count and not coverage. We have some classrooms that have upto 9 AP's with a 4 channel plan and Aruba takes care of the channel assignment and radio power levels. We've had plenty of online tests and the results for us have been like "night and day "... Ken Connell Intermediate Network Engineer Computer & Communication Services Ryerson University 350 Victoria St RM AB50 Toronto, Ont M5B 2K3 416-979-5000 x6709 ----- Original Message ----- From: Kevin Whitney <[EMAIL PROTECTED]> Date: Thursday, June 14, 2007 2:37 pm Subject: Re: [WIRELESS-LAN] Cisco vs. Meru article To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU > 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 > > > > > > -----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] < > > "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/.
