Re: [Server-devel] Wireless Cards in the School Server
Hi Xavier, You could also look up the archive at http://lists.laptop.org/pipermail/networking/ 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. Cheers, Dev 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? > > Thanks, > > Xavier Ziemba > ___ > Server-devel mailing list > Server-devel@lists.laptop.org > http://lists.laptop.org/listinfo/server-devel > > ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
[Server-devel] Wireless Cards in the School Server
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? Thanks, Xavier Ziemba ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
[Server-devel] XO's get bogged down w/ chatter (was Re: Serving 400+ students w/ a single central XS )
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 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 Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Serving 400+ students w/ a single central XS - ejabberd nightmare?
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. Cheers, Dev On 3/8/09, Bryan Berry wrote: > > On Sun, 2009-03-08 at 13:33 +1300, Martin Langhoff wrote: > > Bryan, > > > > 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 > day. > > 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, http://www.olenepal.org > > ___ > > Server-devel mailing list > Server-devel@lists.laptop.org > http://lists.laptop.org/listinfo/server-devel > > ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Serving 400+ students w/ a single central XS - ejabberd nightmare?
On Sun, 2009-03-08 at 22:36 +1300, Martin Langhoff wrote: > On Sun, Mar 8, 2009 at 7:52 PM, Bryan Berry 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 Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Serving 400+ students w/ a single central XS - ejabberd nightmare?
On Sun, Mar 8, 2009 at 10:36 PM, Martin Langhoff wrote: > And you make the Nepal deployment less useful to me too :-( -- you'll > probably have to setup routing and other things on the XS so that > you'll have to carefully debug it to ensure it's not your network > setup before reporting it here. Clear as mud. What I lamenting is that _before reporting a network-related bug_ you'll have to factor out your local network oddities. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Serving 400+ students w/ a single central XS - ejabberd nightmare?
On Sun, Mar 8, 2009 at 7:52 PM, Bryan Berry 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. > 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? > 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... > 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. And you make the Nepal deployment less useful to me too :-( -- you'll probably have to setup routing and other things on the XS so that you'll have to carefully debug it to ensure it's not your network setup before reporting it here. Naturally, it's your call to make. It looks to me like you're getting into a tricky space with routing setup, potential 64-bit OS and other curly issues. If the administrative workload you expect on the XS is really big and tricky, then I'd agree with you... (... but then, I'd like to know what's the big and tricky admin work on the XS? my design principle that it should be super-low-maintenance... ) cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
