Koolu Thin Client
Details of Particular Issues

Contents:

• Speed Tests
• Printing
• Video Driver
• Cryptographic Issues
• Power
• Wireless
• Windows Drivers

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.

Printing

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 http://jacinth.cft.ca.us:631/printers/lp2 ; 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
(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:

• The native resolution of this monitor is 1920x1200 px. In many misconfigurations it will drop back to 1600x1200 px. Some people are trying to get 1920x1050 px for use with HDTV.

• Look in /var/log/Xorg.0.log and consult the EDID to find the recommended modeline. Unfortunately the amd driver does not read the EDID. However, in this forum posting, Sapphire9800 shows the EDID and the right modeline. (Or consult xorg.conf.)

• This modeline uses a horizontal blanking interval too short for a CRT to deal with. The X-server will reject it unless the Monitor section includes Option "ReducedBlanking". On the other hand, if you use a CRT-type modeline it runs the dot clock too fast for the video interface (200 MHz I think) and the driver will reject it (though the driver seems to think the Geode LX can run its dot clock as high as 341 MHz).

• Do not omit the sync polarity; this mode needs +hsync -vsync. With the defaults (both +) the monitor will try to show the mode as 1600x1200 px.

• To get the portrait orientation shown in the picture, I used the command line tool for the RandR extension: xrandr -o left. After digging around on Google I found that this effect could be done in the xorg.conf file: in the Screen section put Option "Rotate" "Left" (not really case sensitive). The same orientation codes are used as with the xrandr command. (One web posting said to use "CW", but for me that value was rejected; this is with xorg-x11 version 7.2. Perhaps the codes are different for version 7.3.)

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.

Power

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.

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.

Wireless

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:

• From Realtek's download site I snarfed their Linux driver for kernel 2.6.x dated 2007-03-xx. (Use wget or a normal FTP client to retrieve it; Opera was not able to.) The tarball contains the source for wpa_supplicant-0.4.9 (SuSE 10.3 provides v0.5.3) and two nested tgz files. A script ./makedrv un-tars the files, cd's to their directories, and does make. The compilation fails because macro INIT_WORK passed 3 arguments, but takes just 2, and also it can't find linux/config.h. My guess is that the driver compiles for earlier kernel versions, but not for kernel 2.6.22. And I'm not going to fix it myself.

• In a SuSE forum one of the people asks why the complainant isn't using the precompiled drivers that come with SuSE. Good question. They aren't on the DVD for OpenSuSE 10.3, but are in the supplementary repository; look for rtl8187-kmp-default-(whatever version) -- there's an update also. (If you're using a different kernel flavor such as bigsmp, replace default.) This package has no formal dependencies but actually depends on rt2x00-kmp, which has a formal dependency on net_mac80211, but the relevant code is included in the default kernel, so use the --nodeps switch of rpm when you install it. (Groan.)

• The interfaces come out as wlan0 and wmaster0. I'm not sure what wmaster0 is for -- probably something important. Now we can do:

  ifconfig wlan0 up
iwlist scan wlan0
It lists networks

  And if I configure the interface I can ping the neighbor's access point. I didn't want to give it an IP on my own subnet because the host already has an IP on that subnet, from the onboard NIC.

  In the course of making a proper SuSE configuration for this device I changed the names to wlan2 and wmaster2.

• But what I really want to do is to make Jacinth behave equivalently to an access point, and to lose the WRT54G. If the NIC had a Prism2 or Prism54 chipset I could run hostap, but it doesn't. I tried to configure an ad-hoc network, like this:

  iwconfig wlan2 mode Ad-Hoc channel 6 key open qwertyioup essid CouchNet2
ifconfig up
SIOCSIFFLAGS: Operation not supported

  Evidently it doesn't like something about my ad-hoc mode. That's as far as I've gotten at the moment.

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.