PC Engines ALIX systems available
As a reliable source for embedded boards coming from Soekris Engineering we’ve been asked many times on wether it is possible to order PC Engines systems from us. Well, we’ve finally made them available through our online shop. We also carry the 19” cases as well as various add-on products.
As a special deal, we currently offer the 2d13 at a special rate.
Why having a LC Display is useful (part 1?)
As we just did a short remote-hands job in one of our server rooms, with me being in a remote location having to tell a Daniel (the newest addition to the bytemine team) when to disconnect and reconnect an external drive, I once again noticed how nice it is to have LC display on the bytemine openbsd appliances there. A quick demonstration:
hanah # lcdalert 10 "hey daniel" "" hanah # lcdalert 30 "please" "disconnect drive" hanah # lcdalert 30 "DONE" "THANKS"
Nice, heh. A short extract from the manpage of lcdalert(8) to explain what it does:
Synopsis:
lcdalert duration line1 line2 [port]
Description:
The lcdalert utility submits two strings with alert priority to the server LCDd. The line1 and line2 are the strings to be displayed by LCDd. Both strings are required. To omit one of the strings, quote an empty string.
I think, it is useful :)
Enjoy!
The display of the bytemine openbsd appliance
We thought, we give you a little visual impression on how cool the display of the bytemine openbsd appliance actually is. There is also a video available, that shows the display and the interaction with the menue as well as the bootloader.
The display is feed through the programm lcdssd(8) which has a set of configurable screens. Through the configuration file all screen can be turned on and off. By default the display shows the hostname and BOA-version screen, uptime and load average screen, physical interfaces as well as the clock screen.
For the physical interfaces the interface name, link-state and IP are displayed:
Additionally with the 1.2 version of the bytemine openbsd appliance we introduced screens for OpenVPN status information. These show the name give to the vpn service, number of connected users as well as the amount of traffic that has crossed the VPN.
I really recommend watching the video, to see all the other screen that are currently available with the 1.2 version of the appliance software. There is also an internal version of the video, but in order to get to see that, you need to contact us and we might share it ;)
Getting started with the bytemine openbsd appliance
In the course of releasing version 1.1 of our bytemine openbsd appliance, we’d like to tell you about some details.
The bytemine openbsd appliance ships with a nice written manual which covers lots of configuration topics. Following OpenBSD’s good practices to write documentation for every file, we wrote man pages for every program and file we added on top of the OpenBSD default installation.
Let’s move on to the first boot of our new appliance.
The bytemine openbsd appliance comes with a pre-installed operating system, however there are certain details, we cannot decide for our users and customers during the installation. That’s where ba-firstboot(8) enters the stage.
The ba-firstboot(8) program will run during the very first boot and will ask you questions like the machine hostname, network interface configuration, nameserver configuration, smarthost for the MTA, timezone and some more stuff. After answering the questions and another reboot, your machine should be ready to be used.
Don’t panic. You can configure the bytemine openbsd appliance just like a regular OpenBSD system if you want. We just added some convenience to get the system up and running.
Learn about the bytemine openbsd appliance system.
A good starting point for learning about our additions to a regular OpenBSD system is the bytemine-appliance(8) manpage. It will explain the first boot configuration, the system startup options and will provide links to other man pages.
So far for the first steps. Following articles will highlight some more details and components.
Have fun!
May I introduce? bytemine openbsd appliance!
It’s been couple months since we announced the bytemine appliance and back when we announced the hardware, we said, it is the building block for a new product line. Here comes the next step!
The bytemine openbsd appliance!
It is built on OpenBSD 4.5 and includes a whole lot of additions, such as:
- ba-update(8) – a software-updater to update your installation with security- and bugfix updates provided by bytemine
- an extended bootloader to support the LCD
- software to make use of the LCD from within the operating system
- lcdssd(8) to display status information
- lcdexec(8) to interact with the keypad and execute commands from the keypad
- mlcd(8), lcdinfo(8) and lcdalert(8) to display various data on the display
- rescue.rd – a rescue system which can be booted via the keypad
- printed manual and documentation of all extensions in man-pages
Through the above mentioned “ba-update” command you can easily update the appliance to always have the latest updates we release.
And for the german folks, here is a poster we did for the bytemine openbsd appliance release bbq last thursday:

LCDproc on github
Yesterday we’ve released our additions to LCDproc on github . The branch can be seen here. Holger, the newest addition to the bytemine team, wrote a driver for LCDproc to talk to the display in our bytemine appliance . Of course we will see about getting our additions to LCDproc to be incorporated into the mainline.
You might want to watch our github repo for more software in the future.
Chemnitzer Linux-Tage 2009 - First public sighting of the bytemine appliance!
Last weekend we’ve spent in Chemnitz at the Chemnitzer Linux-Tage 2009. We took the chance and presented the bytemine appliance for the first time to a broader audience. A few of our customers already had the chance to call one of these babies their own.
I have to say that the the Chemnitzer Linux-Tage are a very well organized community conference. Not only they offer every help possible for exhibitors, but they also managed to put up a very interesting conference programm, that is targeted at the typical audience of such an event.
We arrived Friday night and as such had to put up our booth as well as the OpenBSD booth (which was located in the community area, and bravely guarded by Bernd) on Saturday morning. Our booth was right next to the Zarafa, which made it possible to even further establich our relationship with them (but more on that in a seperate blog post, I promise!)
As you can see from the picture, we even displayed our bytewear! We actually sell these hooded sweaters and t-shirts too :)
Saturday was finished up with a nice social event accompanied by a wonderful buffet! Here is a picture of 3/4 of the miners present in Chemnitz.
We’ve had many interesting talks with visitors as well as other exhibitors and I’m inclined to say:
See ya in Chemnitz 2010!
By the way, you should check out the list of “upcoming events” on our blog, we go many places and love to exchange ideas!
Extended Description from Soekris regarding the problems with CF cards
Recently the errata description for Issue 0006 seems to have been updated. It now lists in much more detail, where the problems come from. Still, it seems rather weird, that all older models, and first generation 5501’s don’t suffer from the problem. We have now contacted our distributor for SiliconSystems CompactFlash cards in order to have a statement by SiliconSystems regarding their CF-standard compliance. Stay tuned.
OpenBSD Network Performance Tests on Soekris and Liantec Hardware
Abstract
Finally, after waiting for more than a year, we got couple of Liantec EMB-5740 prototypes to play with. Since we’ve been selling Soekris systems for years now and lots of customers ask us about performance data, sometimes in comparison to other, similar, hardware solutions, we sat down and compared the Liantec systems to the Soekris 5501-70. This ended as an IPsec performance comparison between the both.
Description
In this test we wanted to determine how much IPSec traffic the Soekris and the Liantec can handle. For comparison, we also made the tests without IPSec.
Test case

The test setup consisted of two workstations (about 1.5Ghz with 512MB memory each) connected via two routers. The first test was done with two Soekris 5501-70, then with the two Liantec boxes. The workstations were running OpenBSD 4.3 default.
To test the throughput of the boxes, we used a tool called iperf. we could have used tcpbench, but that is only available in OpenBSD current (becomes 4.4) and we also wanted to compare our results to 4.3. On server side the iperf was running with “iperf -s -B 10.1.2.2” and on the client “iperf -c 10.1.2.2 -s1 -t100”. “-s1” makes iperf output every second and “-t100” limits the test to 100 seconds. For IPSec we copied the keys from /etc/isakmpd to the other machine.
Technical comparison
The next table is a small comparison of the technical specification of both boxes:
| Soekris | Liantec | |
|---|---|---|
| CPU | 500Mhz (AMD Geode LX single chip processor with CS5536 companion chip) | 1000Mhz (VIA Embedded C7-Eden Platform with VIA PadLock Security Engine) |
| Ram | 512MB | 512MB |
| Usb | 2 | 4 |
| VGA | 0 | 1 |
| Ethernet | 4×100Mbit | 4×1Gbit |
| RS232 | 2 | 2 |
| Heat | cold, even under load | After some hours very hot |
| Form factor | Slim and small, 19” cases available from Kerberos | Fat and heavy; better do not stack because of the heat |
| Stackable | yes | preferably not (see above) |
| Power consumption | 8-12 W | 25 W (with 2 network cables) |
| Price | 266 EUR (33 EUR for case and power supply) | 398 EUR |
Dmesg for the Liantec EMB-5740 and Soekris 5501-70
Kernels
All tests were made with three different kernels. Two were default 4.3 and current (4.4) kernels, the other one was a current kernel without pf. We also did a fourth test with some changed buffer sizes, which we used a current kernel for.
Buffers
Following a FAQ advice, we also testet some different buffer sizes to increase network performance, i.e. we set sendspace and recvspace to higher values.net.inet.tcp.recvspace=16384->65536net.inet.tcp.sendspace=16384->65536
Results
Throughput without IPSec
The following chart is just for comparison, to see what throughput is possible without IPSec. There is just one current (4.4) test as it was not possible to put the Liantecs at their limit with our test-setup, so tuning things would have been useless.
As you can see, in this test case the Liantec box is at least twice as fast as the Soekris. But the results are not really repesentative, because the Soekris was at its limit whereas the Liantec was hanging at about 40% of load. That comes from the fact that the two (older) workstations were not fast enough to fill a Gbit link with packages to put the Liantec at its limit.
Throughput with IPSec
Quite obvious in this chart is, that the Liantec is about twice as fast as the Soekris and that there is just a litte difference between the kernels (see also the next chart). What troubled us is, that while the Soekris has become faster from 4.3 to current, the Liantec box slowed down a bit.
Throughput increase (with IPSec)
This chart compares the increase of throughput from the Liantec box to the Soekris. It uses the same data as the graph before, just a different layout. As the chart shows, there is just a small increase in throughput by disabling features like pf and tuning some buffers.
Load
While testing we also compared the load of the two boxes, with the following results (everything with IPSec):
4.3:
| Soekris | Liantec | |
|---|---|---|
| System | 96% | 97% |
| Interrupt | 2.5% | 2% |
| Idle | 1.0% | 0.7% |
| Crypto | 96% | 96% |
| Throughput (IPSec) | 9.57Mbit | 20.1Mbit |
current (4.4):
| Soekris | Liantec | |
|---|---|---|
| System | 91% | 92% |
| Interrupt | 6% | 4.5% |
| Idle | 1.5% | 2.5% |
| Crypto | 96% | 93.5% |
| Throughput (IPSec) | 9.57Mbit | 20.4Mbit |
The test results are based on the meridian of 5 top(1) graphs.
What is interesting about these comparions is the fact, that the interrupt load has increased from 4.3 to current while system and crypto load decreased. Another remarkable thing is, that there is no scope in throughput with the Soekris, so it is at its limits. On the other hand it seems to be possible to squeeze some mbits out of the Liantec with some smart tuning.
Heat
As mentioned before, the Liantec box became really hot while testing.
$ sysctl -a | grep hw.sensors.lm1.temp
hw.sensors.lm1.temp0=63.00 degC
hw.sensors.lm1.temp1=62.50 degC
Compared to a Soekris:
test@soekris1# sysctl -a | grep hw.sensors.nsclpcsio0.temp
hw.sensors.nsclpcsio0.temp0=124.00 degC (Remote)
hw.sensors.nsclpcsio0.temp1=127.00 degC (Remote)
hw.sensors.nsclpcsio0.temp2=56.00 degC (Local)
test@soekris2$ sysctl -a | grep hw.sensors.nsclpcsio0.temp
hw.sensors.nsclpcsio0.temp0=113.00 degC (Remote)
hw.sensors.nsclpcsio0.temp1=127.00 degC (Remote)
hw.sensors.nsclpcsio0.temp2=51.00 degC (Local)
It is obvious that the results of the Soekris are not correct, so either the Soekris sensor is broken or the OpenBSD driver has bugs.
Problems occured
While testing the Soekris and Liantec boxes some problems occured. First of all, broken Soekris boards suck. One of the test boards was not able to warm-reboot, which can be really annoying while rebooting different kernels. A problem with the Liantec boxes is, that they are way too hot. You have to put them in a cold place and may not stack them, otherwise they will probably die because of their heat. Additionally putting a cf-card into the Liantec is really annoying. You have to disassemble the whole box, which means you have to screw off the entire case, the cpu heat sink and the mainboard. When you are finished, you can easily put the cf-card into the slot on the bottom of the mainboard and assemble the whole box again. Besides that, the test case could have been better. For IPSec and Soekris testing the workstations are fast enough, but for Gbit throughput tests they are not.
What to do next
It would be interesting to test some different buffers and sizes (not just net.inet.tcp.{send,recv}space=65536), e.g. net.inet.tcp.mssdflt or net.inet.tcp.sendpsace=32768. Another interesting test would be to further customise the kernel, e.g. throw IPSec out and see how fast it will be. When there is time it also would be nice to test seperate crypto acceleators like the vpn1401 from Soekris engineering, but from what we have heard, they are worthless.
Summary
Coming to the conclusion of our tests, what do we gain? The tests showed that it is a better choice to use a generic kernel with default settings instead of a crippled one, because this way you only have a performance lost by a few mbit/s but much less maintainance work. As mentioned earlier, the Liantec box is at least about twice as fast as the Soekris, but also more expensive (Soekris: 266 EUR, Liantec: 398 EUR). Which one you will buy depends on your needs, both have major advances and disadvances.





