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