[Server-devel] Network Provisioning

John Watlington wad at laptop.org
Fri Apr 25 14:49:33 EDT 2008


On Apr 25, 2008, at 10:06 AM, Stefan Reitz wrote:

> > >> Theoretically, yes... but perhaps this is a bit over the top.  
> For the
> > >> space we are aiming...
> > >
> > > please define our aim
> >
> > Martin was correct in that the aim of this discussion is rural
> > schools in
> > Peru. Birmingham, NYC, and others will require heftier servers.
>
> Where, if not here, should large school environments be discussed?
> This planet has many very large cities, mostly in developing  
> countries, and I hope the XOs will make it there.

This list is the appropriate place for both discussions, but they are
two different discussions.  Working in large school environments  
provides a
different set of challenges than working in small, rural schools.    
It is the small
rural schools, where normal laptops are unsuitable, where the XO
can make the most difference.

We are trying to support the larger schools as well as we can given
our resources.    The change to APs instead of AAs (for the time being)
is helping in this regard.

> > Please define decent, and how it differs from "cheap". We have run
> > into APs that appeared to artificially cap the number of connections
> > to less than 30 (market segmentation ?), but have also tested $50  
> APs
> > which seem to support 50 users fine.
>
> In the vicinity of another 10+ APs serving 50+ clients each?
>
> > Yes, centrally managed networks of APs are much better.
> > Is that the $300-$450 price you quoted, and does that include the
> > controller ?
>
> How to define decent:
> * keeping a cap on the spreading of broadcast messages.

No WDS and a router, not a switch, behind the APs.  Can this
really be a function of the AP ?

> * not bailing out under load (and recovering gracefulliy if things  
> go wrong).

agreed.  you should see some of the loads we place on these poor APs.

> * providing working quality of service features (hopefully the XO's
> voip / video conferencing client will eventually get off the ground)

I would prefer to see fairness in access to QoS.   We are working with
oversubscribed networks.   QoS simply ensures that one or two students
will have a good experience while the rest get nothing.   Who decides
which students get the good experience ?    And just wait until someones
figures out how to get their bittorrent client to demand QoS...

> This would probably be served with e.g. the cisco AIR-LAP1131AG-A- 
> K9 or 3COM's 3CRWE876075 (or other even pricier products).
> (I don't sell any of these, nor do I recieve any incentives for  
> recomending them.)
> The WRT54(...) are not known to be aimed at anything above personal  
> home use.
> (Ok, I just came across linksys' WAP54GPE which would be in the  
> $380 range and have the suspicous "54" in it's name, but the  
> reviews are less than encouraging)

The WRT54 artificially limits the number of connections to 32, in  
order to protect
Linksys' business model.

One of the points of OLPC was to show that the price of laptops is  
kept artificially
high.    Why shouldn't I believe that the same is true of the APs you  
are recommending ?

> Unfortunately BHM or NYC (...) pose the challenges of business  
> production environments
> (many clients in overlapping areas) and the equipment manufacturers  
> charge what the
> customer can pay. Business customer that is.   I could imagine that  
> a good purchasing
> department is capable of reducing the price by 30% but I don't see  
> schools or school
> boards gaining this kind of expertise (or leverage for lack of  
> order volume).

> None the less, the investment is IMHO still justified by the  
> reduced down time / latency / overall client experience.

In all cases, we are letting the customer decide how they want to  
handle this
tradeoff.   We are trying to steer them away from really cheap  
solutions that
we know will result in poor overall experience, but other than that,  
Peru is
free to choose a much cheaper AP than BHM or NYC.

wad



More information about the Server-devel mailing list