Valid HTML 4.01 Transitional

Koolu Thin Client
Details of Particular Issues

Jim Carter, 2007-12-16


Speed Tests

I've done a fairly complete evaluation of the CPU and graphics speed of the Koolu in comparison with more typical desktop systems (and some high performance computing engines). Here are the benchmark results for the various machines. In summary, comparing to the machine it's replacing, a Pentium 4 at 2.40GHz, the Koolu is 1/6 as fast on an integer test, 1/15 as fast on floating point, and 1/4 as fast in non-3D graphics performance. (There is no 3D acceleration.) It also uses about 1/6 the power and costs less than half as much.

Another test: Using ssh/rsync to transfer a lot of (previously nonexisting) large files to the Koolu, the Koolu used 100% of CPU, charged as 20% rsync (prob. mostly system time for writing) and 80% sshd; while the sending side used a total of 9%; this was an Intel Pentium 4 at 2.4 GHz and the network link was 100 MHz 802.3 Ethernet.

Another test: Transferring a lot of data to another host. tar czf - dirname | ssh . . . (compressing) transfers at 1.58 Mbit/sec; tar cf - dirname | ssh . . . (not compressing) transfers at 43.7 Mbit/sec. Our internal security rules require the use of ssh, which in the second case maxed out the CPU; in other words, if the data had been transferred without encryption it probably could have been moved faster.

Another test: Transferring about 25 Gb of data over 802.3 wired Ethernet at 100 MHz. The command line was rsync --rsh=ssh localdir koolu:remotedir. The Koolu's CPU was maxed out, with 72% sshd, 25% rsync, 2% I/O wait. The transfer took 95 minutes, for an average rate of 35.1 Mbit/sec. Though most of the files were not existing on the remote host, rsync has some overhead even so which decreased the transfer rate below that of straight tar.


To get IPP (CUPS) printing working, I installed the Epson print daemon ekpd. Source can be obtained from Epson's website, but I was able to just copy it (and helper scripts) from the old machine. But printing is a total slug!

The standard paradigm in Linux is that the original file, e.g. PostScript, is sent to the server and is then rendered into the printer's peculiar language and sent directly to the printer. In Windows the client has a printer driver and renders the material into printer language, and sends that over. These files tend to be very large.

I activated raw printing (application/octet-stream), and Windows can send its files (2 Mbytes for one fairly simple web page with just one small photo among the text), and they are printed competently and promptly.

From a Linux source, on the other hand, rendering the same web page as PostScript, Ghostscript totally overloads the CPU, and even on plain text as PostScript (enscript) in monochrome, it can't drive the printer at more than half speed.

How to downgrade Linux to print like Windows does: On the client, install the gutenprint package (formerly gimp-print). My printer on Jacinth is called lp2; I used the web interface to CUPS on the client, and created a different printer which I called lp3. The device URI was ; and I configured lp3 with the same basic driver and the same configuration options as I had done for lp2. This done, Jacinth could promptly print pre-rendered files which the client application printed on lp3.

Video Driver

Sax2, the X-Windows setup program in SuSE, failed to recognize that the amd X-server module was appropriate for the AMD Geode, and gave me fbdev instead, the VESA framebuffer driver.

Jacinth's X-server (fbdev) does not turn off the monitor's lamp when going idle. The framebuffer driver has no DPMS capability, hiss, boo! It's also not all that fast.

I looked around on AMD's Linux download page for possibly a X-server for this chipset. They have drivers for the ACCESS.bus (not sure what that is), the AES crypto accelerator, ALSA audio, Video4Linux, the Xorg Common Patch, and various older software. I downloaded the Xorg Common Tarball.

What's in the tarball: the Common Patch and some sample xorg.conf files. The Common Patch adds the Durango and Cimmaron drivers to the Xorg server collection. Durango is for the Geode GX and has official modes up to 1600x1200px @ 85Hz (dot clock 229 MHz); Cimmaron is for the Geode LX (ours) and has modes up to 1920x1440px @ 85 Hz (dot clock 341 MHz).

It turns out that this driver is v3.0 and is buildable in the context of X11R6. In the X11R7 package the amd driver code is nearly line for line identical but with the header files, data structures and build system suitable for X11R7; it is labelled v4.0. This is the driver that should be used. In the benchmark test it is faster than the framebuffer driver, but not much (0.24 vs. 0.19). However, DPMS works with this driver, which is important for a server where the monitor will spend most of its time unused, and where low power is a goal.

Gotcha: by default it wants to use the EXA acceleration architecture, and that feature gets and reports an error once per second: EXA: Invalid destination format 8040000. In your Device section you need Option "AccelMethod" "XAA" to revert to the old method. Of course a real Open Source Hacker would find and fix the bug . . .

According to this Wikipedia article about EXA, it is an improvement on XAA (X Acceleration Architecture) that speeds up the XRender extension more.

Here is a link to jimc's xorg.conf file.

Digital Signage
Digital Signage (Click for full size)

At work we have an application where a Koolu would be driving a 24 inch monitor: for us, a Dell 2407WFPb (2407WFP-HC). The photo at right shows a demonstration setup, and here is the xorg.conf file used to make this work. Web postings indicate that a number of people have been having trouble making this monitor work, not with the AMD Geode but with desktop machines and graphics cards. The key items I had to overcome were these:

Cryptographic Issues

The AMD Geode has a builtin hardware random number generator. I installed the rng-tools package. The daemon rngd periodically copies entropy from this generator to /dev/random (the kernel entropy pool).

The AMD Geode has a builtin crypto engine for AES. The kernel recognizes and presumably uses it. Link to a blog post presumably announcing this patch. But I can't find any mention of an OpenSSL crypto engine for the Geode.

To use the crypto engine you need the AES Driver Tarball for AMD Geode LX Processors. This contains code for .../kernel/drivers/misc/geodeaes.ko to be compiled outside the kernel tree. But the Makefile does not honor O=/usr/src/linux-obj/i586/default, if the kernel objects and .config are in a separate directory from the source, which they are with SuSE.

Assuming you got this module compiled, you would get devices /dev/geodeaes and /dev/eeprom. There is an ioctl to set the key and mode (encrypt or decrypt); you asynchronously write data to be en/decrypted and read out the result from the device. There are also ioctls to do this synchronously. /dev/eeprom can store several keys which can be permanently locked from being read or changed, but which can still be used by the crypto engine. This would be useful in a cable TV provider's set-top box.

It should be reasonably possible to create a crypto engine library for OpenSSL that uses the crypto engine through this driver.


How much power does the Koolu and its various peripherals actually use? These numbers were measured with a Kill-A-Watt inline wattmeter ($21 at Amazon; thanks, Charlie, for lending it to me). Units are watts, that is, the integral of volts times amps (divided by time). For some purposes volt-amperes are more relevant, that is, RMS voltage times RMS current, and that quantity is higher: about 30% more, at one point where I checked. But the power in watts is the relevant one for the tree-hugging goal. I am not really able to calibrate the Kill-A-Watt, so I'm just assuming accurate numbers from it. It has an origin offset of 1 watt, which is subtracted from all power readings.

The procedure was to start with everything unplugged and to add devices one by one. The change in power is the power attributed to that device. Except, most of the time the monitor is going to be in DPMS off state. In reality I did the whole test and forced the monitor off at the end, but in the table I've synthetically moved that step to just after the Koolu boots.

Devices Total Power Device Power Comments
Koolu (off) 2 2 Power supply only
Add monitor (off) 4 2
Monitor on, DPMS off 4 0
Koolu booting up, DPMS on 43 39 Includes monitor lamp
Koolu idle, DPMS on 42 -1
Monitor: DPMS off 11 -31 Actually measured at end
Add external DVD drive 14 3
Add 7 port USB hub 19 5 Includes keyboard, mouse, net
Add network switch 20 1
Add DSL modem 25 5
Add printer (off) 25 0 4W idle, 9W printing
Add Dell Dimension 4600 (off) 28 3 Machine being replaced
Koolu powered off 16 -12 Keeping peripherals on

So the Koolu performs pretty much as advertised: (slightly) under 10 watts, not counting 2 watts wasted by the power supply. The machine it's replacing, the Dell Dimension 4600, uses 62 watts when idle, for a saving of 50 watts. The whole system, including peripherals, uses 25 watts.

One home-style UPS that I looked at (but have not yet bought) is the APC Back-UPS ES model BE350R, US $36 to $44. Under a load of 25 watts they promise a runtime of 48 minutes, which is plenty if the power failure can be solved just by reconfiguring connections, but which will not keep the machine running through an actual repair. To run the Koolu and peripherals for 24 hours would need 600 watt-hours, theoretically equivalent to 50 amp-hours at 12 volts, a small car battery. (A golf cart battery would last for more charge-discharge cycles, e.g. if you were trying to be self-sufficient on solar power.) A commercially available UPS of this size would be quite expensive.

One annoying power issue is, if the power fails and the UPS runs out (assuming one has a UPS), someone has to press the power button to turn the Koolu back on. If the Koolu is being used for home applicance control or as a VOIP gateway when you are on a trip, you would really like it to reboot when power is restored. Wim Lambrechts did the research, and discovered the following: Jumper J7 on the mobo (near the USB ports, beside the BIOS chip), if moved over, causes the box to boot when power comes on. Koolu technical support does not publicize this feature to reduce the number of people disassembling their machines and causing conflicts over the warranty.


This is not an issue specific to the Koolu, but since the hardware is connected to the Koolu the issue is recorded here.

Presently my laptop, and guests' laptops, connect to our internal net in the conventional way, through a Linksys WRT54G access point running OpenWRT. This device consumes 7 watts, and I would get a big tree-hugging credit if I could transfer the function to the Koolu. I could also get a bigger handle on firewall issues, because my feeling is that OpenWRT is a bit fragile, and I don't feel comfortable tearing into its firewall. Of course there would be no chance at all if I had to stick with the vendor-provided software.

I have a Netgear WG111v2 USB wireless NIC (802.11bg), which uses the Realtek RTL8187 chipset (can't tell if it's a RTL8187B or L). I tried these steps:

Windows Drivers

Wanting to test Windows XP on the Koolu, I initially looked for drivers on the AMD Geode product page, but found Linux drivers only. (It would be worthwhile checking back from time to time, as the company may broaden their support in the future.) However, Wim Lambrechts reports that he found what I did not: on the Mini PC Ion A603 product page at First International Computer is a link to a RAR file of drivers for Windows XP and earlier versions, which appears to be what InstallShield wants to read. (I can't tell if they work with Windows Vista.) He reports that they work just fine on XP. The file includes drivers for sound, video, Ethernet, and the crypto engine.