Fruit and Veg as a Thin Client
- Root ON NFS from raspberry out of the box is broken. The fault is fair and square with the Razzie it tries a version 1 (yes, not a joke) nfs mount request which actually fails on the razzie side. There is a workaround, but it means that each razzie will need the root fs path hardwired into its boot command line.
- Classic XDMCP to Lightdm is broken Debian Bug ID: 878069
There are several key factors which determine the performance of a thin client (more or less in this order):
- Network performance
- 2D Video performance and availability of various 2D acceleration primitives used to move and resize windows
Funnily enough, CPU performance is of little relevance. It takes a really decrepit CPU to fail to keep up with the network and/or the video in order for the thin client to exhibit usability issues. Even the oldest Raspberry Pi models should be quite all right on that front.
While all of this is valid for a variety of thin clients and presentation architectures, some of them try to perform significant optimizations at both network and presentation level. These may (somewhat) mitigate the performance issues even for some of the worst hardware. This is why I do my tests using the X Window system (using the client as an xterm). This allows me to see the issues and get a good idea of worst case performance. So, if it works for a basic use case with X, it is likely to work with everything else as well.
Models 1 and 2 network performance is best described as somewhere between bad and appalling. It is the same issue we see when trying to use Model 1 and 2 with root on NFS. The system consumes significantly more CPU than expected to handle basic network IO. The main difference compared to root on NFS is that this is hidden within the overall CPU usage of the X server or the client application running on it.
As a result, we get pretty bad performance as a thin client. If we grab a window and spin it around the desktop a few times we can easily end up with the mouse being ahead of the actual redraw by up to half a minute.
The fixes to network performance in Model 3 clearly make a difference here. Its performance is improved to a point where it can be used as a viable XTerm out of the box. The drag and drop lag is nearly inexistent and the overall performance is quite good for a 100MBit system.
This is an area where the BananaPi
shines. Network performance is excellent even on the basic early models.
2D Video Performance
The video performance of a Model 1 or 2 Raspberry in a real application is somewhat difficult to evaluate as it is nearly always masked by other factors such as SD card, Network, USB, etc issues. It does seem adequate for the job at hand most of the time. While Model 3 seems to be better, that is probably due to its significantly better IO, not to the video as such.
The video performance of a stock early (Pro, R1, etc) Banana Pi can be described in one word: dire. That is not surprising. By default it has only a very basic framebuffer driver with no 2D acceleration to speak of.
There are two ways of dealing with this problem:
- Use the Mali drivers and matching GL libraries.
- Use the turbofb driver.
These do not do what we want - while the chipset has significant 2D functionality, very little of it is exposed in the Mali OpenGL
enabled binary drivers. Sure, you get some 3D and a subset of OpenGL
, but that does not do you any good for a thin client use case. In fact, the mali drivers have been benchmarked (as a part of the work on running Linux on the Samsung Arm notebooks) to be slower
in basic 2D than a basic framebuffer driver.
They also require a binary kernel component.
This driver has not been updated for some time, which is a shame - it does exactly what it says on the tin. It accelerates the video performance of a basic Mali system by as much as an order of magnitude. The downside is that it is NOT
redistributable, because it violates the X Org license. X Org is licensed under MIT. You cannot arbitrarily restrict the license terms of existing X code by slapping a more restrictive license on it. This is exactly what was done by the guy who developed it originally - he slapped a GPL 2.0 blurb bang in the middle of the MIT license
As a result the driver will never be packaged (legally) as a part of a distribution. This is a pity because some of its code would be of tremendous benefit to other Arm framebuffer drivers. It will work on other Mali based platforms besides the BananaPi.
I have it installed on my Samsung Arm Chromebook (Exynos 5250 Dual Core), which has been coerced into running Debian Jessie. It makes a considerable difference as far as video is concerned compared to both stock Debian and the stock ChromeOS
Xorg build which uses a combination of the framebuffer driver and Mali + OpenGL
End of the day as noone will package it for us, we have to build it ourselves.
All we need is a bit of cut-n-paste from the git project build instructions
We now have a perfect thin client. It has adequate performance for most applications while leaving enough spare resources to run IO and various peripherals.
Thin client/presentation vendors have been showcasing loads and/or presentation applications which run on a Raspberry for quite a while. Let's be honest - it works. It is, however, not something I would use myself (or force on a user) prior to Model 3. Compared to that most Bananas would work just fine with the correct X Org driver.