Technical Specifications

The gory technical details — most people won't want to read this section!

Nimbus is an ultra-thin client to back-end Linux servers running Open Source software.  (An MS Windows desktop can also be provided if necessary -- see below.)

The basic protocol is based on VNC (Virtual Network Computing), which is a standard thin-client technology in the Linux/Unix environment.  This has been extended to support specific Nimbus requirements.


The Nimbus unit itself is the primary client device, but there are also soft-client implementations which allow a user to login to their account from any Web browser (which supports standard Java applets) or any Android device.

This provides full mobility — a user will normally have a Nimbus unit with a full size screen/keyboard at their home or office.  When traveling, it would be possible to just bring the Nimbus unit if a screen, keyboard, and mouse will be available at the destination.  But normally a traveller would just use a PC at a friend's home, or a hotel business center, and access their cloud computer through the Web browser soft client.

If necessary, the Droid phone offered by Verizon or G1Phone offered by T-Mobile can also be used with the Android soft client.  The screen and keyboard on these devices are relatively cramped, but it does provide complete mobility if it is necessary to handle e-mail, check the status of an order, or other basic tasks.

Note: Many more Android devices are expected in the near future, in many different form factors — larger phones, NetBooks, wireless PDAs, tablets, etc.  All of these devices then immediately become available as clients to access your cloud computer.

Note that the Nimbus unit also supports full virtual USB access in order to support printers, flash drives, etc.  The soft clients do not have this capability at this time.


The current implementation uses the standard VNC techniques of detecting frame-buffer changes on the server (at a rectangle level), encoding/compressing these changes, transmitting to the client, and then de-compressing and rendering onto the client screen.  For Nimbus, special encoding/compression logic was developed.  This provides slightly better compression than some of the standard techniques, but more importantly is coupled with a hardware accelerator to handle the decompression/rendering on the client end.

Likewise, keyboard and mouse user input is sent from the client to the server.  This does not normally constitute much of a data load.

The frame-buffer technique works very well for screens with few changes or screens with a limited number of colors (e.g. a black and white text document or spreadsheet).  However, this begins to break down for high-activity screen changes (e.g. action games or movies).  Intermittent frame changes may well be suppressed, and per frame transitions may become visible to the user.

In general, a 1mbs bandwidth is expected and should be fine for most users.  If only simple activities such as e-mail are involved, even half this bandwidth has proven adequate.  Static pictures also perform well, although a Web page loaded with images may take a couple of seconds to download.  (Counter-intuitively though, the user perception of this performance may actually be better!  We've seen several cases of heavy web pages downloading a lot of images and also a lot of behind the scenes data — stylesheets, JavaScript, etc.  Since the datacenter has a high-capacity link directly into the Internet backbone, and only needs to send the screen changes to the client we've seen several instances where the net result is improved performance.)

The NIC on the Nimbus board will handle a 10mbs Ethernet connection, so bandwidth beyond this limit will not improve performance.

A zero copy TCP stack and hardware accelerators at the client side allow us to process screen data as rapidly as the bandwidth can deliver it.

Network latency is the other key factor to consider — even a very high-bandwidth link will not be satisfactory if excessive latency exists between the endpoints.  This will be addressed by using regional datacenters and high-capacity peering links into the Internet backbone or into the head-end of broadband providers with a large number of Nimbus users.

Current testing has shown excellent performance on 1mbs links which have 10-16 network hops between the datacenter and the client.  A Nimbus unit has also run successfully from India (accessing a datacenter in the US), but the latency was noticeable.

Software Details

Any Nimbus client connects to the datacenter through a single TCP/IP connection which is multiplexed internally to support different functions — command and control, diagnostics, virtual USB traffic, and the normal VNC screen/keyboard/mouse data stream.  TLS (the successor to SSL) using AES encryption is used between clients and the datacenter.

The single-TCP approach eliminates problems with firewalls and most other network monitoring devices.  The client establishes a single outbound TCP/IP connection to the datacenter.  No inbound connections are ever required (any required new logical data stream will be carried internally as a sub-channel).

In almost all Nimbus sessions, the screen image data is by far the greatest volume.  Keyboard and mouse input is normally miniscule by comparison.  This situation changes somewhat if USB devices are attached to the Nimbus unit.  Speakers, printers, and flash drives may account for non-trivial portions of the data stream.

ScreenPC developed a unique encoding/compression algorithm to handle the screen data stream.  This was designed primarily so that the Nimbus unit could decode and render all screen image data directly in hardware (see below).

USB data streams are not currently compressed before transmission, but compression libraries exist on both the server and client so this could be implemented easily if warranted.

The software in the Nimbus unit is implemented in C and Verilog (for hardware accelerators).  There is no on-board RTOS.

The soft clients (Web browser applet and Android) are implemented in Java (1.6 or higher).

The Nimbus Unit

This unit consists of a single 5"x6" single-sided circuit board with surface mount components:


All processing power is provided by an FPGA (Field Programmable Gate Array) — discussed further below.  The other major logic chips are 2 8MB memory chips, a USB Host Controller, a USB Hub (in order to make 5 ports visible to the user), a NIC (to drive the Ethernet), and a DAC (to drive the VGA screen).  The rest of the board contains support devices for busses, power supply and distribution, the LED, etc.

The current layout is generous — we thought that making it much smaller than this size would make it look "too small" to a consumer.  Clearly, many other configurations could be considered without changing the basic design:

  • Using the same major chips but squeezing the layout, or using double-side techniques.
  • For an application which requires no more than 3 USB ports, the space for the USB Hub chip and 2 connectors can be reclaimed.
  • If the Nimbus technology were to be embedded within another device, for example a flat-screen monitor, then most of the power logic would be shared and the VGA connector would be eliminated.

What is an FPGA?

An FPGA is an alternative method for providing the processing power within the Nimbus client.  From the factory it represents an array of unconnected logic units (gates), and can be customized for a specific usage by "programming" the FPGA as required for a particular application (the Nimbus client in this case).

Since it is not a full processor (e.g. an ARM or Atom chip) the cost of both the FPGA and its supporting chips is lower.  An FPGA also leaves open the path of converting to an ASIC (Application Specific Integrated Circuit) as volume increases, and driving the unit cost even lower.  The ultimate goal is to have an ASIC-based client embedded within a standard flat panel display at a net cost increase of less than $20 for the "Nimbus-enabled" display.

The programmable nature of an FPGA also allowed us to embed the decompression and rendering logic for the screen image directly within the hardware, thus attaining excellent performance on a very low-cost platform.

Avoiding a standard processor also avoids using a standard embedded operating system, and the complexity and security vulnerabilities entailed.  The Nimbus unit contains no operating system that can be attacked, accepts no inbound connections, and opens a single encrypted outbound connection to connect with the cloud.  Nothing is ever "hacker proof", but the barriers are high.

The current FPGA utilizes less than 50% of the available gates.  The rest have been reserved to provide better handling of video in future releases — either by providing an on-board MPEG decoder in hardware, or instantiating a second 32-bit processor to handle video decode in a hardware/software combination.

Providing an MS Windows Desktop

The standard Linux/Open Source software provides all of the functionality necessary for most users with no software cost or administration.

If it is necessary to provide access to a Microsoft Windows desktop (or a particular application), then a relay can be installed for one user or a set of users.  This utilizes rdesktop, which is open source software which acts as a client to Microsoft's standard RDP (Remote Desktop Protocol) used by it's Terminal Server logic.  Some administrative work is required when the user account is established, but from that point forward the user sees the standard Windows desktop.  (Note that support for USB devices is not available at this time through the relay logic.)

Of course, the licensing and administration for the MS Windows software will also be required.