Some feedback inserted
David,
quick comments as you have short time over there.
On Fri, Jul 30, 2010 at 5:31 PM, David Leeming
da...@leeming-consulting.com wrote:
- One eBox fanless VIA server with 1GB RAM (non-expandable). We had
planned two (one for G3-4 and one for G5+) but vital eqt did not show up
in
time so we are managing with one.
One server should be ok
- Campus wide wireless network, solar powered, using a ratio of less than
30 XOs per AP.
Super!
Layout is 3 x single storey double classrooms (G3A, 3B... 4A, 4B...etc) in
line, separated by about 15m. The server is situated in a parallel line of
classrooms about 6m to one side. We use some centrally located solar power
supplies with POE. The whole system is DC powered and we use digital;
timers
to turn things off when not needed to save power. However the system
provides good access for at least 15 hrs per day.
Great idea on the digital timers -- when you have a chance, documenting
the setup would benefit other deployments.
Will be posting up details on wiki pages when I get a chance. But we are
using Sundaya S4 kist with the 55W panels doubled up with 2A loads or less.
The units are self contained, well priced, and the system is modular so that
if one part goes down due to low voltage it doesn't pull the rest. So far we
have seen the unit with the server (1.5A load) running all night reaching
full charge by 11am even on a cloudy day. The 12V DC digital timers were
sourced from Rainbow Power, www.rpc.com.au)
(Advice on power management): I would like suggestions how the server can
be
safely turned on and off automatically.
I have designed the server so that it survives sanely hard power off.
During development and testing I almost never issue a formal shutdown.
Removing the powercord is de rigueur.
Just don't do it during yum / rpm updates (how I wish those were saner!)
OTOH, given that you have set timers, if everything is running smooth
you know what time power will be off, so you can set a cronjob at a
regular time to run shutdown. (As various clocks drift, this won't be
particularly reliable...)
Daily reboot _not_ needed.
OK, well we have set it up to run 24/7 with the timer override, allowing
teachers to set the timer to auto if need be (but then they will have the
daily task of manually switching it on, that can get neglected in my
experience, especially as the servers are in locked rooms, with the daily
hassle of finding keys etc. Sounds a minor issue but in practice it is best
to have the system as automated as possible).
We also added a line to the cron table (crontab -e) to have a daily reboot
just because we have been brought up to think that is a good thing!!!
... generally the
impression was that networking was functioning well over the entire
campus.
Excellent!
However, we noticed that collaboration was not working well. XOs could not
see all members of their course in neighbourhood view it seemed to be
I would have expected that. The ejabberd server (if you've updated the
RPMs to the latest from olpcxs-testing) will handle many XOs well, but
the neighbourhood view on the XO doesn't cope well with so many XOs.
The cure: segregate presence by course (see xs techniques and
configuration in the wiki for the steps).
We reconfigured with smaller groups (less than 35 per group) and it tested
OK - 6 class groups all independently collaborating and isolated from each
other. As it was the last day and Sunday, we could only do a limited test
with 5 XOs per class but we had Chat running with pretty good responsiveness
(the icon appearing in a few seconds on all laptops) on each of the 6
classes. Whilst this was happening I measured memory use as 184KB total
using ps_mem.py up from 170KB with no XOs active. We'll have to wait for a
monitoring visit to get the data on the full load situation. We only had 2
weeks to do all the training and obviously focused on laptop use and
classroom integration / the pedagogical side, although one teacher was
trained to do basic user management on Moodle. These teachers have mostly NO
previous computing experience.
This contrasts with the good responsive and reliable browsing. In this
test,
we were using presence service split by course, with the students added as
students and the teachers of those grades added as teachers. No-one
was
Hmmm, so even with segregated presence service you are seeing slow
presence issues. Can you confirm yum --enablerepo=olpcxs-testing
update doesn't bring a new version of ejabberd?
Yes was updated. Now works OK (at least based on the reduced load test
described above)
given site roles. The teachers were also members of another course
teachers intended to allow collaboration between the teachers in
different
grades.
That's best practice -- good.
We would like some feedback on what could be the issue.
Very unlikely to be a problem on your end. An ejabberd bug or
ejabberd-moodle interaction issue could be what's
