XS Server Hardware: Difference between revisions
| Line 9: | Line 9: | ||
=Hardware Specifications= |
=Hardware Specifications= |
||
Unlike the current laptop, there will be a number of [[School server]] hardware platforms. OLPC, in order to support the deployment of laptops, especially in environmentally hostile or off-the-grid locations, is designing a reference platform in collaboration with our manufacturing partner, Quanta. We are also supporting efforts by candidate countries (such as Brazil) to manufacture a school server platform locally. |
|||
The School server hardware platform has not been selected at this time. |
|||
The current plan is to provide two hardware platforms. One, XSX, available by mid-March, |
|||
will allow for School server software testing and early deployments in areas where |
|||
power mains are at least periodic if not continuous. The second platform, XS, would be |
|||
reduced in cost and power, and should be available for deployment beginning in |
|||
October. |
|||
Current platforms include: |
|||
* XSX - A short-term prototype, available now using OTS parts |
|||
* An XO laptop - Equipped with an external disk drive, a laptop should be capable of performing as a school server for small (less than thirty laptop) schools. |
|||
* XS - An environmentally rugged, very low power school server for up to 150 students. Should be available in November. |
|||
==XS Specifications== |
==XS Specifications== |
||
This is a [[School server]] hardware platform designed with low power consumption and operation in environmentally challenging conditions as goals. |
|||
This is the hardware platform for actual deployment. |
|||
| ⚫ | |||
The school server must meet all of the environmental constraints of the XO laptop |
|||
with the exception of daily rough handling! |
|||
This hardware platform may be based on any processor architecture supported by the mainstream Linux kernel and libc software trees. We encourage the use of processors supported by Fedora Core 7. |
|||
| ⚫ | |||
Processor performance is difficult to characterize with a single number. We are looking for between 1200 and 1600 MIPs, capable of 120K+ interrupts/sec, with at least 1 GB/sec of memory throughput. At least 256KB of L2 cache should be provided. |
|||
This hardware platform may or may not be based on an x86 platform. Perhaps multiple hardware platforms will be supported. |
|||
For the XS Server, the current processor is the PPC750CL. |
|||
====Reasons to use x86==== |
|||
*Support required for only a single toolchain |
|||
*Able to use an XO as an emergency school server replacement ? |
|||
====Reasons to use non-x86==== |
|||
*Lower power |
|||
*Lower cost |
|||
*Usually integrated with more onchip peripherals. |
|||
===Network Interfaces=== |
===Network Interfaces=== |
||
====Wireless Mesh==== |
|||
What network interfaces should be provided on the School server ? |
|||
The School server will have three [[Active Antenna]], an 802.11b/g [http://en.wikipedia.org/wiki/Wi-Fi WiFi] wireless mesh networking interface. These are connected to the school servers using a three to five meter USB cable. |
|||
==== |
====Wired Networking==== |
||
| ⚫ | At least two [http://en.wikipedia.org/wiki/100baseT wired ethernet] interfaces provides for reliable, high-bandwidth connection between a [[school server]] and its internet connection (if through a [http://en.wikipedia.org/wiki/DSL DSL] or [http://en.wikipedia.org/wiki/Satellite_modem satellite modem]], other school servers, and any non-laptop computer equipment. |
||
How many [http://en.wikipedia.org/wiki/Wi-Fi WiFi] interfaces should be built into the server ? The current proposal is to include two distinct channels (MACs). |
|||
| ⚫ | |||
If we really have 100 students in close proximity, can we make do with only two channels ? |
|||
The number of WiFi interfaces will be expanded using external USB connected WiFi nodes. A reasonable number of these (two to four) can be added to a server to increase the WiFi performance. (* remember that if you do not use highly directional antennas - such as the sector antennas mobile phone towers use - it is highly unlikely that you will be able to use more than three b/g interfaces in a server, due to interference between channels. I would not count on being able to use more than three, each in one of the non-interfering channels 1, 6 and 11. There is a paper in the Mesh Networking Group at Microsoft Research that states they were unable to use more than one PCI - not USB - IEEE802.11g card in a machine, even in different channels. To use two, they had one g and the other a*) |
|||
====USB or ethernet?==== |
|||
Before large scale deployment consider using ethernet (with Power Over Ethernet) to external WiFi nodes instead of shorter max length USB. Although it may well be feasible to separate the 3 antennae sufficiently with USB cables so that transmission on one channel does not flood the physically adjacent receivers on separate channels, it is likely the same deployment will eventually want to re-use the 3 external nodes with longer cables to properly mounted sectoral antennae when available. |
|||
1) Initially use the external nodes with short ethernet cables same as would use with USB cables (ie separate channels 1, 6 and 11). The 3 nodes will be an ugly clutter near the server with either type of cable but should work much the same with either and cost the same. However this is inefficient as two thirds of traffic between neighboring XOs would have to pass through the server since there would only be a 1 in 3 chance of both XOs in any given pair being on the same channel. You are only getting the extra bandwidth on traffic between server and XOs, not between XOs. Could also be more complicated to optimize link distances and mesh diameter when XOs are at home for 3 separate networks than for one, and traffic could be concentrated in one or two of the channels rather than spread evenly across all 3. |
|||
2) Later, when the 802.11s MAC is fully implemented, can add implementation of the "Common Channel Framework" (CCF) extension which uses RTX/CTX exchanges on a common channel to dynamically specify which of the 3 channels will be used for any particular set of transmissions. That should be much more efficient as neighboring XOs can communicate directly. See [http://www.ieee802.org/802_tutorials/nov06/802.11s_Tutorial_r5.pdf 802.11s Tutorial] (from slide 67). Although it may seem counter-intuitive, in practice use of just one WiFi radio switching between 3 channels is likely to give more bandwidth overall than 3 separate radios splitting up the user population within same coverage area. Will also be more resilient when eventually there is interference from other WiFi users. |
|||
3) Then, the sectorized antennae can be used to actually obtain more bandwidth from having 3 separate radios with 3 separate (though overlapping) coverage areas (with all 3 channels used in each). |
|||
4) At the same time the sectorized antennae would significantly extend range of the first hop. That could make a real difference to mesh coverage when students are not at school. |
|||
5) Mounting 3 nodes with sectorized antennas properly could be quite inconvenient with USB cables, not just an untidy clutter. By using ethernet from the start it would only be necessary to switch to longer cables rather than having to replace the external nodes when antenna designs have been worked out and tested and CCF MAC layer extension implemented. |
|||
6) Even simply physically mounting the 3 nodes outside the school, a hundred metres or so apart, without fancy antennae could improve mesh coverage. There are very good reasons why industrial Access Point deployments use ethernet cables with power over ethernet rather than tethering the APs to the hub with short USB cables. |
|||
7) Also there is always a likelihood of [http://tier.cs.berkeley.edu/wiki/Wireless WiLDnet] (WiFi Long Distance) links being added with 802.11a channels to adjacent schools for internet connectivity. These use large parabolic dishes that would definately require longer cables (as would a satellite dish). So ethernet connectors with power over ethernet should part of the spec. Its a lot cheaper to include in the first place than to add later. |
|||
====100baseT==== |
|||
| ⚫ | |||
| ⚫ | |||
====Powerline==== |
|||
This technology has the potential to provide [http://en.wikipedia.org/wiki/100baseT 100baseT] performance over the power lines used to power the school servers. While known as power line communications, the high speed short distance version being referred to here is best represented by the [http://en.wikipedia.org/wiki/HomePlug_Powerline_Alliance HomePlug Powerline Alliance]. |
|||
The advantage is that even if power lines aren't currently deployed in the school, the cable required for powerline networking is more likely to be available/cheaper than Cat-3 or Cat-5 cable. |
|||
A drawback is the lack of standardization and regulatory concerns in many nations. Correcting the regulatory situation isn't necessarily just a matter of time. Powerline networking emits strongly in the lower HF band, increasing the noise floor for existing communication systems (not WiFi, WiMax, or cellular). |
|||
===Other Interfaces=== |
===Other Interfaces=== |
||
What other interfaces should the School server have ? |
|||
====USB 2.0==== |
====USB 2.0==== |
||
At least six [http://en.wikipedia.org/wiki/USB Universal Serial Bus] (USB) 2.0 interfaces should be provided for extending the storage and communication capabilities of a [[School server]]. |
|||
This assumes that up to three external ports will be used for [[Active Antenna]], another for an external CD/DVD RW, another for a possible WAN connection, and one last one for temporary USB key or external USB drive attachment. |
|||
Perhaps four ports, on two separate buses ? This assumes that up to two external ports will |
|||
regularly be used to add additional WiFi channels (or the WAN connection), and two others will be available for external disk drives. |
|||
If no internal WiFi modules are included in the School server, then the number of USB ports should be increased by two. |
|||
===Non-Volatile Storage=== |
===Non-Volatile Storage=== |
||
| Line 101: | Line 51: | ||
====Internal Disk Drive==== |
====Internal Disk Drive==== |
||
An internal disk drive will be provided. This |
An internal disk drive will be provided. This will be SATA (1 or 2). The size of this disk drive WILL vary, with a minimum size of 300 GB at this time. |
||
If the humidity environmental constraints require excessive encapsulation of internal drives, perhaps a single modular and "stackable" approach is optimum. |
|||
Otherwise, including the "first" drive internally reduces cost (less plastic enclosure). |
|||
====External Disk Drives==== |
====External Disk Drives==== |
||
| Line 113: | Line 59: | ||
====Flash==== |
====Flash==== |
||
A fair amount (512 MB) of NAND Flash (solid state non-volatile) memory should be provided on the server to allow the operating system and minimal services to continue operation even though the primary disk drive has failed. |
|||
A smaller amount (512KB) of NOR Flash will be provided for storage of configuration information and boot firmware. |
|||
===Power=== |
===Power=== |
||
Revision as of 09:00, 24 May 2007
This is a description of the first implementation of the School server. It describes the hardware and software implementation details, including the management of services. The actual services provided by the School server are described in the Server Services document, with an accompanying discussion of desired services.
Hardware Specifications
Unlike the current laptop, there will be a number of School server hardware platforms. OLPC, in order to support the deployment of laptops, especially in environmentally hostile or off-the-grid locations, is designing a reference platform in collaboration with our manufacturing partner, Quanta. We are also supporting efforts by candidate countries (such as Brazil) to manufacture a school server platform locally.
Current platforms include:
- XSX - A short-term prototype, available now using OTS parts
- An XO laptop - Equipped with an external disk drive, a laptop should be capable of performing as a school server for small (less than thirty laptop) schools.
- XS - An environmentally rugged, very low power school server for up to 150 students. Should be available in November.
XS Specifications
This is a School server hardware platform designed with low power consumption and operation in environmentally challenging conditions as goals.
Processor
This hardware platform may be based on any processor architecture supported by the mainstream Linux kernel and libc software trees. We encourage the use of processors supported by Fedora Core 7.
Processor performance is difficult to characterize with a single number. We are looking for between 1200 and 1600 MIPs, capable of 120K+ interrupts/sec, with at least 1 GB/sec of memory throughput. At least 256KB of L2 cache should be provided.
For the XS Server, the current processor is the PPC750CL.
Network Interfaces
Wireless Mesh
The School server will have three Active Antenna, an 802.11b/g WiFi wireless mesh networking interface. These are connected to the school servers using a three to five meter USB cable.
Wired Networking
At least two wired ethernet interfaces provides for reliable, high-bandwidth connection between a school server and its internet connection (if through a DSL or satellite modem], other school servers, and any non-laptop computer equipment.
The current plan for XS is to provide at two 1000baseT ports on the server, and four 100baseT ports. Each port will be provided with two LEDs indicating link status, simpliying network debugging.
Other Interfaces
USB 2.0
At least six Universal Serial Bus (USB) 2.0 interfaces should be provided for extending the storage and communication capabilities of a School server.
This assumes that up to three external ports will be used for Active Antenna, another for an external CD/DVD RW, another for a possible WAN connection, and one last one for temporary USB key or external USB drive attachment.
Non-Volatile Storage
Internal Disk Drive
An internal disk drive will be provided. This will be SATA (1 or 2). The size of this disk drive WILL vary, with a minimum size of 300 GB at this time.
External Disk Drives
Additional disks may be added using external USB 2.0 ports.
Flash
A fair amount (512 MB) of NAND Flash (solid state non-volatile) memory should be provided on the server to allow the operating system and minimal services to continue operation even though the primary disk drive has failed.
A smaller amount (512KB) of NOR Flash will be provided for storage of configuration information and boot firmware.
Power
The power specifications of the School server are important. Many schools do not have adequate, or regular, power. While the power consumption should be minimized (15W is a good target), consideration should be given to an integral (or optional modular) uninterruptible power supply (UPS). This is nothing more than a larger version of the laptop power supply!
In some test schools with minimal power, we are already deploying multiple (gang) battery chargers with integral UPS.
Possible methods of obtaining power are summarized in Battery_and_power.
Environmental
The environmental constraints on the school server are similar but slightly less constrained than those of the laptop, at least in terms of water and dirt penetration and drop resistance.
Temperature
The school server should meet the same environmental specifications for temperature as the laptop. This is 50 C ambient.
Water and Dust
This is one area where the school server doesn't have to meet the standards of the laptop. The server should be resistant to water exposure from a single direction (above), but does not have to survive immersion. It should be capable of operation in a constantly humid (100%) environment.
- Can any hard drive operate at 100% humidity ? If the storage device needs to be encapsulated to meet humidity specs., it might as well be designed as separate, easy to replace modules (USB disk units.)
Dust intrusion should be considered. While the server will not contain a fan, it will be air cooled and dust collection on the cooling surfaces will be a problem. User cleanable filtration should be provided on the air intakes and vents.
Connectors and buttons should be resistant to dust intrusion. Buttons should be sealed against water, and connectors located and cables dressed to prevent water intrusion.
Mounting
While the school server should be designed to sit on a flat surface, it should probably also be mountable (hangable) from a wall or post.
This shouldn't cause a problem unless the server includes batteries for a optional/modular UPS...
Drop and Shake
The school server should meet the drop and shake specifications of standard consumer desktop PCs.
- Perhaps the shake specification should be higher to account for rougher transport during deployment ?
XSX Specifications
This is a version with a target date of mid-March. The primary goal is to support development of the School server/laptop software, including early trials. As this is a very limited production model (12-40 ?) and the design criteria are still undefined, flexibility wins out over cost. Off-the-shelf consumer PC hardware is being used for this platform. See the XSX Server Implementation for details.
Selection criteria are:
- 1GHz+ x86 processor
- 1 GB main memory
- four to six USB interfaces, with power for three Marvell Wifi nodes and an external disk drive.
- one 300GB+ 3.5in SATA drive
- power and space for a second disk drive
- two 100baseT network interfaces
- minimal fans
There are no power consumption targets for this device. A separate UPS is suggested for trial deployments in areas of uncertain power.
Software Specifications
The School server should run roughly the same Linux OS as that in the XO laptop. The release process will probably be different, but the kernel and most libraries should be identical.
A description of the software used for the school server in early trials is available.
Development Toolchain
What is the cost of this toolchain being different from that used for the XO laptop?
Upgrades
How is the School server upgraded ?
Service Management
How are services on the School server installed, configured, managed, and updated ?
A web based interface is a natural candidate for performing these actions on the School server.
Scalability
A School server should serve up to a hundred students. We could choose any number as this target, but have selected one hundred for a number of reasons:
- Higher student/server ratios push the processor requirements into the desktop PC range, with their higher prices/power consumption, and require multiple disks to provide the needed storage.
- Higher student/server ratios will probably require dedicated access points in addition to those provided locally by the server.
- Smaller student/server ratios spend too much money on the case and power supply for each unit.
- Ideally, the number of students supported by a single server results in at least two servers in almost all schools, providing a degree of redundancy.
In schools with multiple school servers (the normal situation), the servers are interconnected (preferrably using a wired network connection). They will work together to maximize the performance and reliability of the system.
The management interface for a school will be independent of the number of servers needed to serve the school.
The monitoring and management interface for school server software in a country/region should be independent of the number of server managed.