From the hardware side, the system looks like this:
- Atom N270 system (standard 1.6 GHz) with the ubiqutous Intel 945GSE Express chipset, 1 GB RAM. It's actually incredible how standardised the "netbook platform" still is. These components are available in I guess 99% of commercially sold (not counting "special edition", "vapourware" or "experimental" devices) netbooks. It has done wonders for hardware compatibility and driver support.
- RealTek "8101E/8102E/8102EL PCIe 10/100baseTX" network card. This is one of those really, really bad ones that even suck under Windows. The NIC is from a family of NICs for which the FreeBSD driver has an extensive commentary, starting with: "This is probably the worst PCI Ethernet controller ever made...". The best that can be said about it is that it probably can staurate a 100 Mbit/s link, if the system is not doing anything interesting at the same time (you have to have experience with hardware to realize just how damning this statement is). It took the manufacturer several iterations to get the Windows driver working at all (the default as-shipped driver would fail to achieve anything more than 200 KB/s transfer rates). Even though it claims to support some hardware offload techniques like hardware checksumming and TSO, it works best (and fastest) if those are disabled and done in software (I think the latest Windows driver disables them all by default).
- ICH7 IO, Atheros wireless (not used in this test), Realtek HDA sound and other standard nicknacks that make a computer.
Some benchmark notes:
- The Atom CPU is hyperthreaded, and it's actually not the bad kind of HTT we got with Pentium 4 but a mature implementation that actually can benefit performance instead of being bad for it.
- FreeBSD recognizes and uses all hardware on this machine except for the embedded video camera
- Ipfw was enabled with stateful filtering, with a very small ruleset (11 rules total, HTTP allow is rule #8). This is how I usually deploy servers so I'm testing it.
- Userland and programs were compiled with -mfpmath=sse -O3. This wouldn't really matter if it was any other "normal" system, but Atoms are so slow it actually makes a notable difference.
Tests and results
I've done two types of tests, over localhost and over LAN, using Apache 2.2.10-worker. The first is serving a static file. To be as less as little innovative as possible, I'm serving a single file of 6825 bytes in size. (it is a copy of /etc/login.conf, present in all systems). The second is serving a PHP file, a simple script of approximately 2000 lines, doing mostly string manipulation. PHP is 5.2.10, with APC as the opcode cache, used as FastCGI with mod_fcgid (this is also the setup I deploy by default).
The full results are here and I'll only present the peak performance summaries here:
- Static file over LAN - peaks at slightly over 1400 TPS at 32 concurrent clients, which isn't all that great. The system cannot saturate a 100 Mbit/s link.
- Static file over localhost - peaks at slightly over 750 TPS at 4 concurrent clients, which is worse. Apparently all that contention and context switches have a big inpact on the small system.
- PHP script over LAN - peaks at nearly 500 TPS at 32 concurrent clients, which is very surprisingly good, and suggest that the NIC could be the bottleneck, not the CPU.
- PHP script over localhost - peaks at slightly over 360 TPS at 16 concurrent clients, which is again worse than over the LAN but also surprisingly good overall.
The PHP script, again, is very, very simple, but apparently the performance of the Atom-based system is good enough to power a simple dynamic web site - 95% of blogs on the Internet would be extremely happy to have an audience of 1000 visitors per second!