Re: [Server-devel] notes on scaling ejabberd for the XO's

2009-03-11 Thread Dev Mohanty
More info available on the wiki at:

On 3/11/09, Bryan Berry wrote:

 Here are some notes from a short IRC conversation I had w/ Rob Mcqueen,
 the lead developer of Telepathy

 transcript of conversation on #sugar
 bemasc: bernie: I am concerned about the fact that in the default
 schoolserver set up all users are in one giant shared roster
 Robot101 RESOLVED, ALREADYFIXED (but not in any deployments, or in the
 BryanWB and the resulting chatter slows down the XO/Sugar
 Robot101 yes
   Robot101 rwh
   the latest versions of sugar and telepathy support using an XMPP
 component called gadget
   instead of the shared roster
 BryanWB Robot101: so gadget fixes this?
 Robot101 yup
   Robot101 rwh
   you only receive push notifications about a) what Sugar has searched
 for/displaying on the neighborhood view, or b) your friends
 -- hgcphoenix (n=hc...@ has joined #sugar
 BryanWB Robot101: neat, and does it work together w/ the XS?
   Robot101: which version of sugar is it in?
 -- hgcphoenix (n=hc...@ has left #sugar
 Robot101 they went off on a complete tangent trying to hack shared
 rosters to have less mutually visible sets of people
   we thought of that but also decided it was the bong, so we fixed it
 properly with gadget.
 BryanWB Robot101: what is the testing status of gadget?
 Robot101 it's deployed on (which is on
   seems to work fine, ejabberd seems to gradually leak memory though,
 which isn't too great
   maybe a little much CPU usage on gadget, but nothing you couldn't
   and I'm not familiar enough with the sugar release cycle to say where
 the support went in
   Robot101 rwh
   eu daytime is better to find the Sugar devs and the Collaborans who
 worked on Gadget
   (cassidy, daf)
 BryanWB Robot101: ok, will talk w/ them later today
 Robot101 gadget was always our plan, it just took us a while to get to
 BryanWB Robot101: by the way last year we tested ejabberd by streaming
 your video talk on Telepathy to 80 XO's
 bemasc Robot101: I believe martin dropped the shared roster, and
 inside is simply using moodle to set all rosters directly.
   bemasc bernie benzea
 Robot101 bemasc: so it's still shared as in server-enforced mutual
 visibility, just in smaller groups.
 bemasc right, but from ejabberd's perspective, it's individual rosters
 Robot101 that's exactly how shared rosters always work
 Robot101 the client thread gets a copy of the same roster at sign in
 bemasc oh? I thought there was a patch to ejabberd required.
 Robot101 yes, he's patched it to source the shared roster from moodle,
 I'd imagine
 bemasc martin seemed to say that he could use a totally stock ejabberd
 Robot101 oh, right. sql query or something. our patches were just
 extending the built-in shared roster to a) work properly (deal with
 dynamic additions and removals) and b) support a group of online users
 rather than everyone

 Bryan W. Berry
 Technology Director
 OLE Nepal,

 Server-devel mailing list

Server-devel mailing list

Re: [Server-devel] Serving 400+ students w/ a single central XS - ejabberd nightmare?

2009-03-10 Thread Dev Mohanty

I remember the Linksys routers used to drop connection, as soon as 33-34
clients were logged in, and as Bryan
mentioned we got much better perfomance with the readily available
Taiwanese brand
of APs. With a Linksys 25 odd clients works just fine though with heavy

With the Linksys WRT54G /L/S variants, its important to note the version (eg
5.1/ v6/ v8) and chip used (Atheros/ Broadcom) as
only certain versions support full funtionality, with opensourced firware.

Here's a good table to refer to:


On 3/10/09, Rangan Srikhanta wrote:


 Here at OLPC AU, we are using Linksys WRT54GLs using DD-WRT and configuring
 the routers to act as an AP according to the following instructions.

 I found I could turn the WRT54GL into the required AP mode in 10minutes,
 using an XO.

 In our first round of deployments we will be only using WRT54GLs, and after
 speaking to Dev, will be working on 1 for every 25.



 *From:* [mailto:] *On Behalf Of *Reuben K. Caron
 *Sent:* Tuesday, 10 March 2009 11:29 PM
 *To:* Daniel Drake
 *Cc:* server-devel
 *Subject:* Re: [Server-devel] Serving 400+ students w/ a single central XS
 - ejabberd nightmare?

 Daniel Drake wrote:

 2009/3/9 Bryan Berry

 We will have roughly 8+ AP's. We have found that off-the-shelf AP's can

 handle around 60-70 users.  But that doesn't still doesn't solve the

 problem of the XO's getting bogged down by tons of ejabberd chatter.

 DSD: do you have any ideas about this?

 Have only had a chance to test numbers on Linksys WRT54Gsomething

 routers, which stop accepting new connections after 33 users. yay.

 Have you tried loading a different firmware on these, dd-wrt?

 Server-devel mailing list

Server-devel mailing list

Re: [Server-devel] Wireless Cards in the School Server

2009-03-09 Thread Dev Mohanty
On 3/9/09, Marten Vijn wrote:

 On Mon, 2009-03-09 at 17:51 +, Dev Mohanty wrote:

  You could also use the APs in repeater mode with the same SSID, if you're
 planning to use more then one AP.

 no that is no very handy if want some performance, a repeater eats
 bandwidth from the AP.

True, using an AP as a reapeater does compromise on your bandwidth, guess
its only helpful in cases where you're wanting to extend coverage and not
ness improve connectivity.

Best for performance
 - big antenna's antenna's  (reduces noise from clients)
 - channel planning
 - ap's in bridging mode (no routing or NAT)

 *Configuring your APs to use different channel from one another.

In a classic E.U (U.S.?)
 - a server is in a server room
 - ap is in the class room
 - maybe use PoE ( over your wired network


Server-devel mailing list

Re: [Server-devel] Serving 400+ students w/ a single central XS - ejabberd nightmare?

2009-03-08 Thread Dev Mohanty
Bryan I assume, this is in reference with the deployment planned at the
new schools, and guess am more then familiar with admin workload and
power limitations you
happen to mention in Nepal.

Hence was wondering if you've looked into the option of using more then one
XS, installed at the same location (eg DOE, OLE) if not at the
schools, this might make it a lot easier to administer. One XS could cater
to students in 3 schools while the other could register students/XOs from
the other two schools, for load balancing.. As am not too sure that using
additional RAM would get the desired results. And
ofcourse there's the 4GB RAM limitations on a 32bit processor, unless you
plan to use a PAE switch and tweak the kernel too and guess
that would be getting into murky waters.

Besides, as Martin pointed out using a 64bit processor would
require the XS iso to be completely
rebuilt, which might take a while forthcoming. Though, I've heard that
AMD's Athlon processors are backward
compatible with 32bit applications and permit use of more then 4GB RAM
without PAE, guess food for thought if you're adamant on using just one XS
for all the schools to reduce the overhead.

But still believe getting ejabberd to
perform with 400 simultaneous users, might still be a tough task.


On 3/8/09, Bryan Berry wrote:

 On Sun, 2009-03-08 at 13:33 +1300, Martin Langhoff wrote:
  I'm on the road, apologies if I'm a bit succint...
   - 400 users are unlikely to be online at the same time, supporting
  all users online at the same time will stress all the infra, so the
  path to success is, I suspect, paved with strategies to define usage
  patterns that avoid clustering everyone at the same time.

 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

   - I am working on 0.6 which will let you partition the school --
  instead of @online@, large schools can set moodle+ejabberd in a mode
  where users are in a shared-roster-group defined by their course
  membership in moodle. I've posted on the list and written in the wiki
  about this before if you need more detail.
   - More users - more RAM to the server :-) and disk space for backups

 we can provide that

   - Do you really have a low latency / high bw conn between the schools
  and the location with the XS? I have the feeling we had this
  conversation before... :-) and I suggested smaller and local, which is
  how the XS is designed to work. That's still my recommendation...

 The XS is quite a complicated ensemble of software having an XS at every
 school magnifies the administration work. Having a centralized XS for
 several schools can dramatically reduce administrative overhead.

 Additionally our schools only have about 8 hours of electricity per day.
 I am concerned about the XS losing power suddenly multiple times per

 We have a relatively low latency connection b/w the schools and the XS.

 We have discussed these issues before and I believe that we both came to
 the conclusion that Nepal has different requirements than some of the
 other pilot schools.

 Bryan W. Berry
 Technology Director
 OLE Nepal,


 Server-devel mailing list

Server-devel mailing list

Re: [Server-devel] Wireless Cards in the School Server

2009-03-08 Thread Dev Mohanty
Hi Xavier,

You could also look up the archive at Guess hasn't been very
active lately, but then
has plenty of info and reference to the wiki. Should get you started and
help you with most of your queries.


On 3/8/09, Xavier Ziemba wrote:

 I've been working on configuring an XS server for the Cambridge Friends
 School in Massachusetts and have a couple of questions regarding wireless
 networking and the XS server. Does the XS software support automatic
 configuration of PCI wireless cards within the server itself? The
 documentation on the OLPC wiki seems to suggest that using separate wireless
 access points through a wired interface is supported; would this be a better
 solution for this deployment? Also, how would I go about configuring the
 appropriate links between network interfaces if I used wireless cards within
 the server?


 Xavier Ziemba
 Server-devel mailing list

Server-devel mailing list

Re: [Server-devel] Ubuntu XS

2008-08-17 Thread Dev Mohanty
Would be interesting to know more on Uruguay's Debian based XS.. any links?

Besides, if I remember correctly, I guess Tony Pearson was also part of 
that team or maybe not. I have mixed feelings about the current XS 
builds, guess I'd have preferred the XS being a lot more efficient and 
to run out of the box then what one gets off the latest image, as I 
believe a considerable amount of time has gone into it. On the other 
hand am not too sure if changing to core OS would resolve anything, it's 
more about getting the right packages in and getting them to function as 

Maybe at this point it makes sense resolving the bugs with the current 
XS, instead of trying to port it to a Debian based distro. As Martin 
points out the non-functional 80% kind of stands out. But then if you 
guys do eventually decide to have two concurrent versions of the XS and 
plan for a Debian based XS.. count me in on it. Maybe competition for 
good is the need of the hour!


Michael Stone wrote:
 On Mon, Aug 18, 2008 at 07:41:13AM +1000, Pia Waugh wrote:
 There are a few interesting feature requests I've had from local trials,
 including the ability to only allow an XS to talk to approved XOs, to
 avoid strangers parking outside a school with an XO and interacting with
 children (worst case scenarios are always the first thing on a Government
 agenda :), so we're looking at MAC address management on the server
 potentially. More to come!

 Uruguay already uses a Debian-basex XS (which is quite different from
 Martin's) and which includes some MAC-address filtering technology.
 (They've also expressed great interest in expanding this technology into
 a full 802.11i/802.1x/EAP/RADIUS authentication system, which seems like
 it might be of mutual interest.)

 Greg Smith and Emiliano Pastorino could probably give you some good
 introductions if you'd like to try to collaborate with LATU.

 Server-devel mailing list


Server-devel mailing list