Input requested on thin clients for Project Caua
Paw Prints: Writings of the maddog
Project Cauã (www.projectcaua.org) is starting to evaluate configurations for a Thin Client. Actually we have been thinking about thin clients for some time, and trying to find a good design to meet all the needs of the project. Although we have some general ideas, a long time ago I realized I was not omnipotent, and that the best way of finding good information was to pose the question to the FOSS community and let them help you solve the problem.....
First, some design considerations for the thin client. The design considerations below are purposely a little vague and are acknowledged as incomplete. We did not want to limit people's thinking too much, and wanted to offer some flexibility in the design.
Secondly, while we would like to find an existing board or thin client from an existing manufacturer that meets the goals of Project Cauã, we anticipate that the volumes of thin clients required will generate an opportunity to create an open design that could be manufactured by many manufacturing companies. So we are really looking for two things:
- An existing design that could be purchased for prototyping, pilot and initial deployments. Specific current products (including model numbers, URLs and your reasons for recommending) are appreciated.
- A "dream specification" that would fit the vertical markets, has long life and flexibility. This would allow for upcoming technologies that Project Cauã should be considering.
Therefore please read the following design considerations listed below and feel free to comment and suggest alternatives, even to the design considerations themselves:
Thin Client Design Considerations:
Form factor does not have to be super-small:
While "small" (mini-ITX, nano-ITX, pico-ITX, etc.) is a nice movement, we envision most of the thin clients being attached to the back of an LCD panel via the VESA mountings. Since LCD panels are fairly large (and seemingly getting larger), the thin client case itself can be relatively long and wide. Cooling and printed circuit board layout are often helped by having a "bit more room" in the case to put components and heat sinks. Motherboards can often have fewer layers in the larger boards, allowing for lower costs of manufacture.
Intel-compatible instruction set:
Probably the most controversial requirement. However, with long experience from the Alpha line of processors, it is very difficult to get pre-built packages for that last two per cent of the software you need, and it seems as if 90% of the people need that last two per cent.
Non-Intel instruction sets are fine for very specific devices (phones, embedded systems, browser-only systems) but these thin clients are general purpose devices, and it is envisioned that parts of the application may migrate between the thin clients and the servers.
No harmful chemicals used in the system.
All controllers should be well documented to allow source code drivers:
These systems have to last 9-10 years, therefore all device drivers need to be "open"
The BIOS should be completely in source code, and "open"
Should not need a fan:
Fans always seem to wear out fast, and even faster in an environment by the ocean where there is a lot of salt spray and the fans corrode. Likewise most fans are noisy.
Should be able to run in ambient temperatures above 60 degrees Celsius (140 degrees Fahrenheit):
Of course a lot of people will say that 60 degrees Clesius is too hot and no thin client should have to run in those temperatures, but we need to have a system that can run in enclosed areas that may not be air conditioned, and the ambient temperature can get very high. If we want the thin client to work inside a car on a hot day, for instance, the temperature could get even hotter than 60 degrees C.
The thin client system should support virtualization:
At the very least there will be one virtualized environment running an external mesh network while the "main" virtualized environment is doing the work of the client-side thin client. The virtualization should be as efficient as possible
Should run off a range of voltages that "surround" twelve volts:
Due to the car industry, twelve volts is a very prolific voltage for things like portable refrigerators, audio amplifiers, even portable microwave ovens. A lot of embedded systems exist for twelve volts. Likewise in many "off grid" areas, twelve volts is relatively easy to generate because of the availability 12 volt solar panels and of automobile alternators that can be hooked to bicycles, water-wheels and wind turbines. Twelve volt car batteries can be charged and used to power the twelve volt systems when the primary power source is not available, even in on-grid situations.
However, not all twelve volt systems create "exactly" twelve volts, so the thin client should be able to run on a variety of voltages from 14 volts to 10 volts, to allow leeway in voltage variances.
Goal of less than 10 watts:
While this goal may not be met by the prototypes or pilot models, the over-all project would like to have less than 10 watts as a goal
At least one wired high-speed ETHERNET port:
Each thin client will be hardwired back to the server system, so having a hardwired ETHERNET controller of 1 Gbit or above on the board makes sense
Many USB 3.0 ports:
As a trade-off to long life, various components that might be considered to be desirable on the motherboard due to volume manufacture and lower costs could be addressable through USB devices. Some newer components are still going through rapid evolution (as witnessed by the WiFi movement of "b" to "g" to "n"). Digital TV tuners might also be addressable this way, as the standards change from country to country.
At least 5.1 surround sound audio:
One of the markets for the thin client is home theater. Having the proper circuitry for reasonable audio output to plug directly into a self-powered speaker system or set of "surround sound" earphones would be nice. Of course this could also be done by USB audio controllers, but at added cost.
At least "high definition" video output:
One of the markets for the thin client is home theater, so the video has to support at least 1920 x 1080 (1080p). Ideally the thin client would be able to drive two separate video output streams at this resolution through DVI connectors built into the motherboard, but a video controller running off USB could also drive one of them. VGA is not required.
Support of full screen video and low-order 3D graphics:
The system should support standards that allow full-screen "High Definition" video and a reasonable amount of 3D graphic effects to allow modern-day window managers to work well.
While all of the above areas are not "cast in concrete", and comments are welcome, there are some areas that could definitely stand more discussion:
While "more memory is always better", it does use power, create heat, and take up space on the motherboard. How much should we allocate for a thin client to have a lifetime of 9-10 years?
While we expect that most thin clients will not have any disks attached, Project Caua would like to give the capability of the thin client motherboards to be paired together to make a small highly-available server, and for this possibility, or for "data caching" SATA on the motherboard would be good to have, or perhaps an eSATA connector on the back. On the other hand, USB 3.0 could also be used for disk drives.
Legacy (serial, parallel and VGA):
These options could be provided through USB connectors, and their speeds are not so great that (with the possible exception of high-resolution VGA) that they would put a strain on the CPU. Therefore it is suggested that they not be take up space on the motherboard.
Flash tends to degrade over time and USB flash is fast enough and cheap enough to allow flash to be provided through USB
60 GHz WiFi:
As mentioned before, WiFi is changing rapidly, and 60Ghz is on the horizon. Should this WiFi be included on the motherboard, or be yet another USB technology?
These thin clients will be financed, so more important than keeping the initial cost low is longevity, functionality. stability, and low cost of maintenance.
Ease of maintenance:
It is expected, with no fan and (in most cases when used as a thin client) no disk, that the entire unit would be returned to a repair/recycling center if any hardware issue occurred.
As I stated above, these requirements are purposely a little vague, incomplete and flexible as possible to stimulate discussion and as wide a variety of answers as possible.
I will be reading the comments in this blog, answering some of them for clarification and rolling them up into a report that will be published here later.
Thanks for your consideration and help.
maddogcomments powered by Disqus
The Raspberry Pi Foundation has announced an even smaller version of the tiny computer that will fit into a DIMM slot.
A new class of problems lets a malicious app pre-configure an invisible privilege update.
New Hack language adds static typing and other conveniences.
New crypto policy system will offer easier configuration and more uniform security.
Ubuntu founder denounces insecurity in proprietary, close-source software blobs.
Vulnerability affects many Linux web servers
The Bavarian capital shuns Microsoft, Google, and other alternatives to implement an open source groupware solution.
Phone vendor partnerships bring Mark Shuttleworth's dream of Ubuntu on a phone a step closer to reality.
Donors will get to vote on new features for the free video editor.
Debian project puts init out to pasture and says no to Ubuntu's Upstart.