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