I just want to reiterate the following because I have gotten several
e-mails suggesting solutions to scaling the XS. 

The Dell server handles this problem fine. I expect the MSI wind PC will
handle it fine as well.

The problem is w/ the ___XO's___ NOT the servers. It is hard for the
XO's to keep track of all the conversations happening

The problem w/ centralization is creating a huge giant shared chatroom.
It creates a ton of "chatter" that the XO's have to keep track of.

I need to find the upper limit of how many XO's can share one roster
w/out getting significantly bogged down.

On Sun, 2009-03-08 at 16:57 +0545, Bryan Berry wrote:
> On Sun, 2009-03-08 at 22:36 +1300, Martin Langhoff wrote:
> > On Sun, Mar 8, 2009 at 7:52 PM, Bryan Berry <br...@olenepal.org> wrote:
> > > But 200-300 users could be online at once. I think it will be too
> > > complicated to tell some of them: "Don't connect to the AP right now,
> > > you may overwhelm ejabberd"
> > 
> > Give ejabberd enough RAM and it won't be a problem. The rest of your
> > infrastructure will, however.
> I am worried about the XO's and not the XS.
> I used the hyperactivity program and got some unscientific results. I
> simulated 200 users using the schoolserver constantly. The CPU of the XS
> was very busy, staying near 100% usage during the account creation
> period and then it leveled off. I didn't monitor it very closely after
> that b/c ejabberd is not my chief concern
> This dell server has a dual-core Xeon 3.0 GHz processor and 2 GB RAM.
> RAM was fine, beam only used 450 MB according to ps_mem.py
> sudo ./hyperactivity.py gabble schoolserver.schoolnet.gov.np 200
> I ran hyperactivity from my regular dell laptop
> My XO showed 200 users in the Network View and became very sluggish. Top
> showed that 30-40% of CPU was taken up w/ handling the sugar-shell, the
> program which manages the Network View. The dbusdaemon was using roughly
> 15-20% of the CPU. I tried to launch one our E-Paath flash activities
> and it hung displaying the error message "Unresponsive script". I tried
> to launch EToys and it failed as well.
> > > The XS is quite a complicated ensemble of software having an XS at every
> > > school magnifies the administration work.
> > 
> > What admin work do you foresee on the XS?
>       * Making sure that ejabberd keeps running
>       * Making sure that the school doesn't have roof leak directly
>         above the XS
>       * Making sure the schools doesn't remove the power cord and use it
>         for something else
>       * Make sure the school doesn't repurpose the UPS for the XS for
>         charging cell phones
>       * make sure the XS doesn't get zapped by a sudden power surge
>       * Making sure it is there 3 months later
>       * Make sure that dansguardian, squid, dhcp stay up week after week
> We don't have any problem gettting the kids to take care of the XO's but
> we have a Hell of a time making sure they take care of the XS
> > > Additionally our schools only have about 8 hours of electricity per day.
> > > I am concerned about the XS losing power suddenly multiple times per
> > > day.
> > 
> > Good point. I've been building everything with daily "poweroffs" in
> > mind and every component should handle it. But haven't field-tested...
> Sadly, no one has and this is one of my chief concerns
> > > we can provide that (RAM)
> > 
> > Have you go the 4GB barrier in mind? Past 4GB we get into all sorts of
> > problems. You'll need a 64-bit machine, and you'll have to convince me
> > or someone else to build a 64-bit XS iso rather than the vanilla
> > 32-bit we're using now.
> > 
> > > We have a relatively low latency connection b/w the schools and the XS.
> > 
> > Low latency, high bandwidth and everyone in the same netblock? No
> > routers in the middle. That's what the XS assumes, in any case.
> > 
> > > the conclusion that Nepal has different requirements than some of the
> > > other pilot schools.
> > 
> > Everybody is a little bit special. By deviating from how the XS is
> > designed to be deployed, you will add mgmt work to workaround whatever
> > gotchas.
Bryan W. Berry
Technology Director
OLE Nepal, http://www.olenepal.org

Server-devel mailing list

Reply via email to