Talk:XS Server Hardware

Please keep leaving comments. They are read, and taken seriously. The XS spec will get overhauled in the next week to reflect recent decisions and plans.--Wad 10:56, 23 April 2007 (EDT)

Teacher PCs and VGA Connectors

There will be at least as many teacher PCs requiring power as school servers. Each teacher will need their own XO to carry around but will ALSO need an adult sized keyboard and mouse AND an adult sized display. USB HDD, keyboards and mice should be no problem. (Though a standard USB keyboard that can be marked with key labels identical to those on XOs should be made available as it will reduce learning difficulties for teachers). Can probably use the teacher's XO tablet but adding a separate tablet no problem either.

Adult sized display IS a problem. Teacher resistance would be magnified if they have to use child sized display for their work. It is NOT the same as using XO as a cute second PC for portability as experienced by developers (and by teachers if and only if they DO have a less cute first PC on their desktop). Using adult USB keyboard with child sized display wold be very awkward (and teachers using XO keyboards EXTREMELY frustrating).

This must be factored into design of power generation for schools with no power. Unlike student XOs it is both necessary and feasible to supply adequate power directly to each teacher PC within a school in the same way that it is necessary and feasible to supply power to the school servers and gang battery chargers for the student XOs.

In areas with electrification this is no problem. Elsewhere it may imply that school will need to have a diesel generator rather than being able to do it with solar.

I haven't found a section on teacher PCs which are also critical to success of deployment as there will be enough hostility from teachers without making it harder for them to get to grips with it all. Please point me to it if there is one. Meanwhile I will add some thoughts here.

Many will use existing desktop or laptop with X windows to the teacher's XO. That adds significant support hassles. Many others will not have an existing desktop or laptop and will need to be provisioned at same time as school servers.

Optimum solution for lowest cost and lowest additional power budget is to offer a standard VGA or USB low power display eg like a laptop screen without the rest of the laptop. These would need to be sourced and included in the supply chain that delivers servers and internet connection and power generation to schools at lowest wholesale costs as buying retail would be major cost and hassle.

Surely and optimum solution would be to put an XO board in a bigger case with a bigger screen. If you are going to ship a million XO's then assuming a pupil teacher ratio of 1:25 then you will need 40,000 computers for teachers. A sufficiently significant number I would have thought to justify the cost of additional moulds for a bigger case. Screen is a bit more problematic at this number I suspect but I would have said that a 12" or 13" screen at 1024x768 would be sufficient. -Jabuzzard 14:40, 18 May 2007 (EDT)

Very likely that displays much cheaper without USB and using ordinary VGA LCD monitor (not especially low power) or even an old CRT. Old 17" displays are being thrown out and could be supplied for teachers without the hassles of reconditioning old PCs. When thrown out they are either working or not, and if working can just be used with suitable power connector.

Optimum solution is to just plug in the teacher HDD, mouse, keyboard and display to the teacher XO. When they need more can add a "brick" and also use it as a port connector.

USB 2 VGA connectors do exist but are very expensive as they have to replicate the video electronics already included with the Geode chipset on XO. (May also impose substantial extra load on XO?)

So teachers should be provided with an XO that has a VGA connector.

The arguments against including a VGA connector in every XO are sound in view of component cost for the connector itself (the additional passive components also required should be negligible extra cost).

These arguments do not apply to providing a variant XO model for teachers. Same PCB mass production line would be used, with occasional batches adding the VGA connector for teacher model. (I would also include the associated passive components on all XOs and design the connector solder pads so that people can easily retrofit a VGA connector to student XOs, as unlike the connector itself the cost would be negligible compared with the potential benefit for extending useful life when students need larger displays and have power available to use them).

Main issue is that the case needs both the hole for the connector and a cover to maintain water and dust resistance when nothing connected.

From prototype board it appears the existing VGA connector is positioned at the top of the board. So it should be feasible to just modify the top cover piece so it has the hole and a separate cover like battery compartments.

Doing this NOW would mean the same injection moulds for mass production of student XOs would also provide both Teacher XOs and the option to retrofit a VGA connector for all XOs at negligible manufacturing cost.

Omitting this means substantial additional costs per teacher for either support of variant teacher PCs, expensive USB to VGA connectors or entire desktop or laptop PCs plus additional teacher confusion and resistance.

Could somebody please confirm that this issue has been drawn to the attention of whoever is finalizing the injection moulds for the case right now. It is a separate issue from the decision not to provide VGA for student XOs and needs to be considered in the light of server deployments and school power requirements that would not have been fully considered when designing the student XO case.

Arthur

PS The hole and cover and associated solder pads could also be made large enough to support other possible future retro modifications like passing out the DETTL connector between onboard display controller and XO display to an external larger sized display screen that uses identical tehnology to the XO display and/or passing out standard antenna connectors so that directional antennas can be easily fitted where students are otherwise out of range of the mesh when at home.

Scalability

Doing some quick math based on Argentina Statistics, at the national level you have 5,151,856 kids in K-12 grades in 27,888 public shools, giving ~180 laptops / school (or ~3 servers / school).

Does the internet connection scale for larger schools ? Does a 60 student school have the same access as a 240 student school ?--Wad 00:22, 2 February 2007 (EST)

Good or bad? Don't know.

PRO

Multiple servers could improve coverage, redundancy and available storage.

CON

Higher costs per school (depending on alternatives), multiple failure points and/or administration.

We are deploying just one (overpowered) school server per early trial, and will obtain a better idea of the requirements. The final number may be 120, or 50...--Wad 00:22, 19 March 2007 (EDT)

As a note specific to Argentina, the educational system is split in 4 three-year chunks: EGB I, EGB II, EGB III + polimodal (being only EGBs compulsory). Multiple servers could support 'administrative' layers or frontiers between these different 'levels'—acting like some 'sub-network' division.

This is just a guess-list. Please add at will. PoV is subjective... so a con may sometimes be thought of as a pro depending on the overall context. For example, redundancy could be thought as good if it's simple and straight forward out-of-the-box(es), but if to administer the multiple servers you must do it in a totally different way than when you just needed one, then it can be thought as a con given the penalty to growth.

There is no question that a single school server will be targetting a maximum number of students, the only question is "how many?" I can design a server capable of serving 20 students, which will fail miserably if you try to use it stand-alone in a school of 200. I can design a server which can handle 800 students, but it would be overkill for a school of 30.--Wad 00:22, 2 February 2007 (EST)

One possible XSX hardware

I've been running FC6 on an HP dc5750 (and just ordered another). It can be bought in a standard minitower. AMD chips, ATI Radeon XPRESS 1150 graphics, Broadcom gigE. Ten USB slots (2 on internal headers). Has fans, but they are very slow/quiet in normal operation. I can't hear it in my living room unless my head is very close to the fan. I bought it with the Athlon64 X2 Dual Core Processor 3800+ (35W max), which reduces the CPU max power/heat by half, and with the 80PLUS power supply which is more efficient, thus less power/heat. ($40 and $20 options.) Has two SATA disk slots and 4-way mobo SATA controller. No PATA. 2 PCI slots, 1 PCIe 1x, 1 PCIe 16x (you'd need to add an Ethernet card, since this only has one GigE).

PRO: available from stock, or with a few weeks leadtime for custom config. Quiet, low power, no Microsoft tax (buy the "FreeDOS" version).

CON: ATI chip undocumented and poorly supported (works great for 2D graphics, nothing better). Minor issue when running FC6: Linux driver for the ATI chip barfs over the optional LightScribe DVD+-RW, for unknown reason, though FC6 install DVD worked great during installation from the same drive! Solved by adding a $17 Rosewill RC-210 PCI SATA card for the DVD (it also gives you an external SATA port for a faster ext hard drive than USB can provide). Linux has no trouble accessing disk drives on the motherboard SATA - just the lightscribe DVD writer. lm-sensors can't see the motherboard sensors; it's probably the *%&$$ ATI chip again. (Maybe yr buddies at AMD/ATI can help you with this.)

HP's optional EM718AA memory card reader (plugs into the floppy slot and a motherboard USB header) does NOT support SDHC, so avoid it. I tossed theirs, and added a $30 YE-DATA YD-8V08 memory card reader and floppy drive, which DOES support SDHC. Newegg.com has it (and the RC-210 SATA).

I've noticed that when plugging in USB or SD cards, sometimes Linux doesn't immediately notice and DTRT. If you plug in something else on USB, then it figures it out. Don't know whether this is hardware or FC6 software problem.

Thanks for the tip. We are currently looking for fanless systems, and are exploring miniITX motherboards. They easily meet the requirements listed for the XSX.--wad

I have been using mitx motherboards for some time under FC2 & Ubuntu 6, 7. They would make an excellent motherboard for the school server.--brian 21:43, 22 May 2007 (EDT)

Should spec GigE w/autoX

The server should talk GigE. In 2007 there's no point in deploying 100BASE-T. In any school with more than one server, these boxes are all going to want to talk to each other, accessing each others' disks, etc. Ethernet is not just the uplink to the Internet; it's the disk access bus for the whole school. Why bottleneck NFS, remote backups, DVD/CD reading and burning, etc to save 15c?

Actually, it is more like $6, and the wiring to make use of it is slightly more expensive. Yes, it would be nice to have 1000baseT for the school backbone but it is not worth making a requirement, yet. In small schools with a single server, it is a wasted cost. Even in larger schools, the backbone may be wireless.

The difference between a brand new PCI card complete with packaging and shipped to me with 1GbE and 100Mbps is less than $6 in the UK. I would expect the cost of an integrated solution on the board to be around $2 extra --Jabuzzard 03:02, 22 April 2007 (EDT)

I strongly advise making the ethernet port(s) on the server do the automatic-crossover thing, so that there's only one kind of Ethernet cable, whether or not you're using a hub or just plugging two servers together directly with cat5. And put a link light on it, so there's immediate physical level feedback when it can see the other end of the cable.

Very good suggestions. Automatic crossover is part of 1000baseT, but still might carry a cost on 100baseT. The need for link lights is well known.

I suggest sidelining the powerline ethernet stuff. The last thing you want to have to debug in the field is half-assed networking. (I finally bought a USB ethernet card for my XO - Linksys USB200M - and am much happier.) Major companies have been pushing powerline ethernet for years and they get no traction. Why? Haven't tried it myself but the feeling is that it isn't reliable, doesn't get real spec'd throughput, etc. RJ45/cat5 ethernet is so simple, cheap, and so widely deployed that it's almost impossible to screw it up. Once switches replaced hubs (and there were no 50 ohm terminating resistors from the coax days) it all just went plug-and-play; with the widely deployed spanning-tree algorithm, even loops don't faze it. If somebody really wants to run powerline, there are external adapters from cat5 to powerline.

The concern is wiring costs (which are always much more than just the cost of the wire). Power is likely to already be available at all servers. I have tested powerline networking, and it can work fine, but can also be stymied by some devices such as home computers and small electronic appliances which have input circuits which try to minimize the RF intrusion. Phoneline networking works much better, but phone lines are less likely to be in place than power, and if wiring must be done there it probably costs the same to install Cat5e as Cat1. --wad

The main cost in doing wiring is the labour. There is a massive difference between putting in a single link to connect two servers and doing full structural wiring. The first can be done quite cheaply, the second requires all sorts of additional stuff like patch rooms, panels, racks, containment, ... Powerline networking is a hugely expensive technology that performance wise sucks. Given the cheap cost of labour in the target countries putting in Ethernet links is the sensible route. It also builds local expertise up which can only be a good thing. --Jabuzzard 03:02, 22 April 2007 (EDT)

Or, another option: If you build powerline ethernet into the server, build it straight into the power plug/power supply. One plug both powers the unit and hooks it to powerline networking. Include a separate GigE port or two. Then, as soon as you plug it into power, if the powerline stuff works, great, it'll be networked. But there'll always be another method that's known to work. Make sure you can turn off the powerline stuff (or that it's off by default) in case it hashes other things by adding RFI to the power wiring. Also see what effect it has on nearby Marvell chips :-). (PS: If nobody builds a PC power supply that includes powerline networking on the same cord, maybe there's a reason why.)

Actually, the reason is mostly due to the economics of the PC industry...

It won't affect nearby Marvell chips, but it will greatly affect shortwave AM and SSB radio reception in the surrounding area. I am not a fan of powerline networking by any means, but if it worked, in many situations it would be a better candidate than 802.11a, the other economic (no new wiring) option. 802.11g is out as we don't want the backhaul in the same spectrum as used for the mesh networking. --wad

Failure Points

Drives and fans will get you. If you can't eliminate them, at least plan for frequent failures at awkward moments. AlbertCahalan 10:32, 22 March 2007 (EDT)

The plan is to have no fans in the XS school servers. The very early XSX prototypes (off-the-shelf) will probably have a fan (w. bearings) in the power supply, also helping with the overall system (disk and processor) cooling.

Drives are a different matter. We need them to economically provide the amount of storage the school server needs. And due to economic factors, we aren't considering RAIDs. The XS server will, however, include sufficient OS on NAND flash that it will continuing providing networking functionality even if the disk fails. And user generated content on the school server should be backed up continuously. --wad

Not sure what you mean by "user generated content on the school server should be backed up continuously". Where "should" it be backed up TO? And do you mean that the humans there "should" back it up (somehow), or that the server software "will" back it up?

There's no substitute for offline backups -- particularly offline backups with write-protect switches. No software glitch can erase them while offline, nor can they be easily trashed when plugged in for recovery, if the write protection is engaged. (Can you tell I was trained in the mainframe era?) External hard drives (eSATA or USB) are the obvious thing, but few come with working write-protect switches.

If a school has two XS or XSX, they ought to back each other up automatically. Big drives that can hold twice the data have only a small price premium over small drives. Making this automatic for two servers would be pretty easy; but getting the general case right (N servers on the LAN, or N servers divided up on several locally linked LANs) is hard without manual configuration. The idea is that no piece of data is stored on a single spinning drive; it has to be replicated til it exists on two drives, preferably on two different servers. And then, if one fails and a new drive is installed, there's a simple path to full recovery. (A company I work with, called ReQuest.com, makes home theatre music systems with hard drives. They automatically back up your music collection if you have several of their units. Saves many customers from trouble. Making them buy two servers if they want backup is expensive, so it probably shouldn't be the only way to back things up. But since many customers will already have two or more, having them back each other up is almost free, and vastly improves your chances of keeping the kids' and teachers' data.)

Power Budget

You are never going to make a 8W power budget for the server. It is utterly unrealistic. A 3.5" hard drive will take that alone. One thing I would do is pick a wide range input power supply for the main board, there are lots of these available that take anything from 6-30V input, something similar to the XO itself. You can then use a battery backed PSU instead of an UPS. These are much more efficient, have less components and are thus more reliable. --jabuzzard

Hehe. I just made an account to leave exactly the same comment. For example the Seagate 7200.10 300GB drive takes 9.3watts IDLE. You'll have better luck with 2.5" laptop drives. The Toshiba MK2035GSS is around 0.85 watts idle and about 2watts under load, but I expect such drives to be more expensive into the near future. If the 8w number is a real target it might make sense try to keep the normal working set in ram/flash so that the drive can sleep most of the time. --Gmaxwell 01:28, 15 April 2007 (EDT)

Not only is a 2.5" drive much more costly, the performance tends to suck. The largest 7200RPM 2.5" drive, a Seagate Momentus 7200.2 is only 160GB, but for the same price you can get a 500GB 3.5" drive! The largest 2.5" drive is a Fujitsu Mobile MHX2300BT, but this only has a spindle speed of 4200RPM and is not yet shipping. The largest currently available capacity on a 2.5" drive is 200GB still with a spindle speed of 4200RPM, at the same price as a 750GB 3.5" drive. There is no way you are going to handle 50 users with a 4200RPM drive, and for the price of one 2.5" 7200RPM drive you could have a RAID-1 of 250GB 3.5" drives. It is clear that the power budget was proposed by someone with not the faintest clue. --Jabuzzard

External SATA

The suggested specification has USB2 for adding extra hard drives. Think is that hard drive performance on USB2 is terrible, even Firewire at 400Mbps hugely outperforms it. However from a cost perspective most chipsets these days come with at least two, and many have four SATA ports. All you need to do is bring these to an external header. A eSATA enclosure is cheaper simpler, more reliable, uses less power and faster than messing about with USB2. That said I would look to have at least two if not more hot pluggable slots to take SATA drives in the main server case to enable swapping them and upgrading. Having drives dangling of USB or eSATA cables in the proposed deployment scenarios for a server is a recipe for disaster, and the drives are going to fail. --Jabuzzard 03:15, 22 April 2007 (EDT)

Let me second the suggestion to provide an eSATA connector. USB drives are, indeed, slow, and they tend to have bizarre failure modes (I ran two in production for months -- but blocks read back as zeroes, very occasionally, and I was never sure whether the drive failed, the write over the USB bus failed, the read back over USB failed, there's a kernel bug in how it deals with USB storage, or what). eSATA costs nothing but a connector and some passives, since the chip already supports it. Also, S.M.A.R.T. does not work over USB, but it works great on SATA and eSATA. SMART has actually worked for me in several ways, mostly in letting me find rotting disk blocks with weekly scans and fix them manually before they became a problem. But also SMART warned me that a drive was about to go -- it had allocated all of its spare sectors suddenly -- and I got my data off it before it failed. --gnu

Many external drive enclosures support both eSATA and USB. However, for a production server I would NOT spec an external drive that doesn't include a fan. I have used a variety of external drive enclosures, most of which had no fans. Particularly when doing lots of seeks (serving many clients), the drives ran way too hot for their health. Even opening the boxes and running the drives naked in the air didn't reduce their temperature to reasonable levels. Perhaps the high operating temp is why I was getting blocks of zeroes. Not what you want to debug in remote regions of the world in the product that enables Internet access for a thousand kids.

The only totally sealed disk drive I've run was the Silent Systems enclosure, which puts a 3.5" ATA drive in a 5.25" slot by surrounding it with two metal plates, a plastic box, and noise absorbing foam. Would probably work for SATA, if your cable isn't too stiff. It reduced the drive noise significantly, and of course protected against dust & etc. The metal plates conduct heat out past the plastic case to where there's fan airflow. The drive lasted for 5+ years in this setup, mounted inside a normal PC with a quiet fan. But it was spec'd for only low-end drives that didn't produce much heat. Molex bought the company. Search www.molex.com for SilentDrive or "Thermal Acoustic Products" (they have no working URLs, it's all javascript crap).

Updates

Should the upgrades possibly be downloaded from the Internet, and then flashed to the respective devices (Bios, mass storage). In the event of the server's internal storage going corrupt, the server should be able to boot off of a USB drive (as no optical drives will be available).

Suggested specification

I have been mulling it over for the last couple of weeks and here are my thoughts on the XS, based on my experience of trying to do something similar for a small low powered ethernet/wireless gateway come home server. Obviously I had to go with off the shelf components, but much of this is still applicable. I managed a 20W system though much of that was down to using a 2.5" drive.

One presumes that you are having custom boards made specifically for the XS in this. I also presume that it is not quite as cost sensitive as the XO due to the smaller numbers.

Processor

I would go with an AMD Geode LX-900, advantage is that it gives you the same tool chain as the XO. Means you can easily develop software for an XS without the complications of cross compiling (and storage penalty) or having a tool chain on your server (not a terribly sensible idea as it makes it that bit easier for hackers). The power consumption is only a bit over the LX700 in the XO, but the extra CPU speed is worth it.

x86 low powered processors comparison

Processor	Clock Speed	Architecture	L2 Cache	Typical Power	TDP
AMD Geode™ LX Processor 700@ 0.8W	433 MHz	130 nm	128 KB	1.3 Watt	3.1 Watt 1
AMD Geode™ LX Processor 900@ 1.5W	600 MHz	130 nm	128 KB	2.6 Watt	5.1 Watt 1
AMD Geode™ NX Processor 1500@ 6W	1.0 GHz	130 nm	256 KB	6 Watt	9 Watt 2
Intel® Celeron® M Embedded (Ultra Low Voltage) 373	1.00 GHz	90 nm	512 KB		5 Watt 3
Intel® Core™ Duo Embedded E7520	1.20 GHz		2 MB		9 Watt 4
Intel® Core™ Solo processor U1300 (Ultra Low Voltage)	1.06 GHz	65 nm	2 MB		5.5 Watt 5
Intel® Core™ Duo processor U2400 (Ultra Low Voltage)	1.06 GHz	65 nm	2 MB		9 Watt 6

¹: AMD Geode™ LX Processor Technical specifications

²: AMD Geode™ NX Processor Family

³: Intel® Celeron® M processors for Embedded Computing specifications

⁴: Intel® Core™ Duo Processors for Embedded Computing Specification

⁵: Intel® Core™ Solo processor Ultra Low Voltage

⁶: Intel® Core™ Duo processor Ultra Low Voltage

--ScottZhu 13.10, 6 May 2007(EDT)

For RAM I would use at least 1GB. The reason being that you sound like you are going to be using a standard hard desktop drive for the XS. I don't exactly know what the access pattern is going to be but 100 users on a 7200RPM drive is going to be tricky, you need lots of RAM to compensate. It should also mean you don't need swap which makes life simpler.

Display

Assuming that you are using the same OpenFirmware/LinuxBIOS, or even a pure OpenFirmware choice, I would drop all keyboard and display and use a serial console. A cheap USB to serial converter can then be used to do the stuff that would normally require a keyboard and monitor. Just make sure you use a decent D socket, the cheap ones are only good for 50 mating cycles, where the best are good for 500.

There are options for serial consoles over ethernet using IPMI, and it might even work wirelessly, though this might be a bit of a security risk.

Normal maintenance could be done either via ssh or a custom web interface.

Power

A wide ranging DC input like the XO should do the trick. That would allow lots of power options from universal AC-DC power bricks to solar panels. Note you are going to need significant quanties of current at 12V to power 3.5" drives if you used those.

No server should be run without a UPS of some sort. The most efficient way is to build this into the system as a battery backed power supply, similar to a laptop than a traditional AC-DC-AC separate UPS. I was going to suggest sealed lead batteries but LiFeP would also work and is more environmentally friendly. A scheme where several XO batteries are used to for this to boost capacity would be worth exploring. Commonality of components is always a good idea.

Storage

I would stick at least 512MB if not 1GB of onboard flash to take the OS. If the machines have enough RAM then the magnetic storage can be used purely for data storage. I am assuming that you are going to use 3.5" for the main storage for cost reasons. Though 2.5" is much lower power.

For the main storage I would provide four SATA interfaces with NCQ. The NCQ should help a bit with dealing with 100 users on a 7200RPM drive, and it does give you the option of pluging in SAS drives if you want (all SAS drives will work on a SATA interface). Personally I would avoid external storage altogether and provide four hotswap disk caddies per machine. Firstly hard drives fail, and will be the number one failure point by quite some margin. Making it easy to change them when they go wrong is a good idea. Secondly external boxes are prone to damage, being unplugged etc. they also require power, and it is way more efficient if that power is provided by the main machine. You can provide cheap plastic fillers for unused slots. There are lots of four drives in the size of three half height 5.25" bay devices that would be suitable.

I would reconsider the rejection of RAID. Hard drives fail, and this is going to bite you real hard if you only have single disks. I cannot emphasis this enough, don't do it. On this line some hardware accelerate RAID would be worth considering. Also consider some of the M+N cluster file systems, for automatic fail-over in schools with more than one XS. The mesh networking could make it all seamless; server goes down but through the mesh you pick up a second server and just keep going.

Smart monitoring hooked up to some external alarm indicator would be sensible, especially with RAID.

Wireless

I would used USB2 based thumb drives on the end of a USB extension cable. The reason behind this is that it allows for easy antenna placement away from the machine without having to worry about precision coax cables. A wireless antenna near a metal case sucks, as the case tends to act as screen. With USB you can get 5m/15' from the case no problems.

Has the wireless been trialed? 100 laptops trying to connect to three points in close proximity should be a nightmare! The 802.11 channels overlap horribly and the number of concurrent connections drags down the S/N ratio even with 10 clients. Matching the providers of the laptop and server wireless controllers should improve matters. The mesh networking may also help, How intelligent is the mesh networking? Does it route according to the congestion on the nearest host or the network as a whole? Does it handle muticasting? With 33 connections through each laptop, you are likely to see some slowdown on the laptop closest to the server.

I'd recommend rotation of clients for big pushes, so connect a smaller number of clients to the server at a time, rotate through all the clients, for example, to download a resource like a video or textbook which will be used that day.

Networking

You only need one actual ethernet link, and I would make it 1GbE. Forget about powerline it is expensive and has lots of other problems. Stringing a bit of Cat 5e/6 to link two XS's is really quite cheap. It is only full structured wiring where things get expensive.

To provide uplinks I would provide a PCI slot, which can be used to provide ADSL, ISDN, analogue modem and if necessary a ethernet. Keeps things neater and tidier and less prone to unplug problems than separate boxes. It is also much lower power, and you can use the internal UPS to power it all. For example a PCI ADSL card is about 2.5W, where an external ADSL router with power brick is typically 20W. There are some issues with binary blobs for PCI ADSL cards you could perhaps commission your own with these stored in on board flash to avoid these problems. There are also binary blob issues for most PCI fax modem cards. Again on board flash or real serial port on the modem would fix that.

Enclosure

The bulk of the enclosure size will be for the drives, especially if you go for 3.5" drives. If you want to go for a sealed case, you main problem is going to be the drives, again especially if you go for 3.5" Take a look at the Hush range of machines [1] if you want to go sealed, but it will add significantly to the cost as you are going to need some large chunks of external aluminium heatsinks and heatpipes. Fanless is one thing, sealed is whole other ball game.

For drives I really recommend making them hotswap, something like the following [2] I repeat, drives fail. At work by enterprise SCSI drives in dust free air conditioned rooms still fail. Seen failures within a year of new systems.

I would say something the size of a four bay 5.25" SCSI case would be about the right size, if you are going to allow for four internal drives and internal batteries. Something wall mounting along the lines of the PACK-BOX is worth considering. [3]

--Jabuzzard 06:34, 6 May 2007 (EDT)

Real CPU, real RAM, high compatability, and what's the GUI?

Don't put an underpowered CPU and RAM in this thing! Not only will it have to do backups and help the XO's collaborate, but it's going to be the only thing accessible to the kids where they can actually run COMPILERS. What good is the "View Source" button if the kids can't change the software? Python will just interpret today, but I hope that PyPy will eventually make it run much faster after compilation. And all the C and C++ modules are going to need to be recompiled. In addition, any kid or teacher who interfaces with the rest of the free software world is going to need to be able to pull down source code (in SRPMS, .src.debs, tar.gzs, diffs, or whatever) and build it. Don't make the server grind to a halt for 50 or 100 kids because somebody wanted to rebuild the video chat program with a newly downloaded codec. -gnu

Running a server for compiling programs requiring local accounts etc. is asking for trouble. Only a fool would allow this. There is nothing stopping one from installing a full toolchain on an XO if that is what you want to do. --Jabuzzard 04:24, 8 May 2007 (EDT)

Jabuzzard, this wiki is not the place for calling people a "fool" or their ideas "twaddle". I suggest that YOU install a full toolchain on an XO and demonstrate that it runs and is usable. I believe there are many things stopping one from doing so -- like limited RAM and limited flash space. We can barely get the web browser to run on XO, with one tab and no GUI -- that's RUN, not compile! And have you tried building Sugar on the XO, ever? I don't think it has EVER been done. Sugar-jhbuild barely works on high powered computers with full Internet access. Also, the last time I heard, the students aren't going to get an RPM-able build that new programs can just be added to, it'll be locked-down and the same on every student's machine. --gnu

Running a full toolchain on a production server is only something a fool would do. I make no apologies for saying so. As for running a tool chain on an XO, it has a 466MHz processor with 256MB of RAM and 1GB of flash; sorry but I ran for years on less than that doing development. The XS is not going to be particularly higher specified that an XO anyway so a couple of users doing a compile would bring the server to it's knees, leaving the other 50-100 users suffering unacceptable levels of performance. Exactly why using a multi user server as a development box is a stupid idea. You just dont't do it.-Jabuzzard 10:07, 19 May 2007 (EDT)

Put in as much flash on the server as on the OLPC. Make your life easier. If it's going to boot from flash, it should be able to run the same software releases, and probably the same boot OFW. (Even if it won't run an identical image, the images should be the same size -- don't force the software guys to juggle to make it fit!) -gnu

Put an SD card slot in it! It should be able to access the same peripherals as the OLPCs in its area. What a shame if a new software release would come in, be sitting on the hard drive, and be unavailable to write it on any portable storage medium that the OLPC can read. (Yes, wireless, but it's slow, and less dependable than a memory card. And do you plan to ship USB keys with the unit? SD is cheaper, smaller, faster, and lower power, and fits inside cleanly.) -gnu

The network is the computer. The OpenFirmware on the XO now has a wireless driver specifically so you can do a firmware update over the air. Messing about with SD cards, or USB pen drives when you could just suck it over the network is silly. Besides the XS would have a USB interface, and SD cards are not appropriate for moving between machines as they are simply not rugged enough.--Jabuzzard 04:24, 8 May 2007 (EDT)

The biggest question is what's the user interface. Are you going to make an OLPC be the keyboard and screen for it? That would take some work to build an interface (USB?). Serial ports and terminals, uggh! Or is it going to have a VGA port, take a standard monitor and PS/2 or USB keyboard and mouse? Or include an OLPC screen and OLPC keyboard and touchpad built-in? There's gotta be a way to run it and debug it, and you don't want the chicken-and-egg situation where an XO needs the server (e.g. as a mesh gateway) but the server needs an XO (e.g. as its gui) -- so whenever one breaks, the other gets very clumsy and unhelpful. -gnu

This is complete twaddle. If you read what I have written above you can put in a bog standard RS232 port, and use a serial console. Then a 10USD USB-serial lead can be used for low level BIOS configuration, bare metal recovery etc. and a SSH session or web interface can be used for everything else. The chances of every XO that would access a XS being in an unusable state when you need to setup an XS is so vanishingly remote that it does not need to be considered. Adding a display controller, and associated hardware is a completely unnecessary cost. --Jabuzzard 04:24, 8 May 2007 (EDT)

The UI to the server needs to be spec'd and is conspicuously absent. If it's going to be SSH-over-wireless or VNC-over-wireless then it still needs a low level method for when the wireless isn't working (e.g. the disk drive is failing). The reason to avoid "serial ports" is because there is no such thing as a "bog-standard" serial port. 25-pin or 9-pin? +/-12 volt RS-232, +/-5 volt RS-449, or 0-5V TTL levels? Male or female? Cross-over or straight thru wiring? Any control lines required or supported (like DSR, RI, DCD)? There aren't going to be any "terminals" or "modems" handy to plug in. The only use of the proposed "USB to serial" cable will be to attach an XO to the XS when it fails, which means that this sole, critical, cable will get lost or stolen during the year that the XS runs before failing. -gnu

If the low level method is going to be "serial", which is probably a good thing from a hardware debug / software debug point of view, then the physical interface to that "serial" interface should be a USB cable that's permanently attached to the box, with an ordinary USB connector on the end. That cable would be plugged into an XO's USB port (or any Windows or Mac that has a driver for the USB-to-serial chip). The USB-to-serial chip should be on the XS motherboard, so that the entire interface to the XS is USB, not serial. (You could include an additional DB-somethingorother serial port on it under the hood, "for emergencies", but it won't get used in the field.) This USB cable would be like the USB cable attached to a mouse, or the VGA cable attached to a monitor -- with one end permanently attached to avoid mischief. In the schools there will probably not be any USB A-to-B cables lying around, no serial cables of any sort, etc. The one advantage of serial over USB is that it can be run for long distances, e.g. if the XS is buried in the rafters of the school. -gnu

I don't think having a long cable attached to a server is a very good idea. All sorts of problems with it getting snagged, the end trailing all overt the place an getting dirt and possibly short circuited. However the idea of putting the RS232 to USB chip on the XS motherboard and bringing it out to a USB B socket is a very good one. USB cables are very cheap, easy to come by and a couple can easily be included with each server. An additional thought would be to include a driver for the USB-serial interface in the Open Firmware, so that even if every XO was unable to boot into a full OS, you could still do low level recovery on an XS using an XO. -Jabuzzard 10:07, 19 May 2007 (EDT)

There's still zero discussion of how humans interact with the XS

No keyboard, no mouse, no display, no serial, no VGA, no tiny LCD touchpad, no nothing is written in the XS Server Spec! At least put in a placeholder saying, "We know that humans will have to interact with it sometimes -- particularly when its hardware or OS is broken -- but we haven't decided how."

I think Larger XO is the answer

Two issues;

1. XO keyboard is too small even for 12~13 years old children,and, even worse, children grow year to year.
2. How about teachers? parents? even worse, not only developing nations are participating OLPC.

Making additional VGA port and keyboard port on the XO mold is irrational. Where are moniters and keyboards for them?

The solution is quite clear. We should start to design a larger XO case to be used for (1) school servers, (2) local servers, (3) country servers, (4) teachers and (5) unfortunately large children.

Extra expense? there also is a quite simple solution.. why NOT sell Larger XO to worldwide citizens?

Of course, I know it may be a political issue rather than technical/economical/educational one. If selling/distributing those larger XOs to citizens worldwide, then there will be millions of wireless relays/routers providing internet connection/VoIP communication...what a nightmare to laptop or communication firms worldwide...

But, I think there is no such simple and efficient solution but designing a lager XO case. php5 08:53, 10 June 2007 (EDT)