Traditional relational database management systems are simple to understand, but it can be difficult to model ‘real-world’ systems – especially if you want to denormalise the database in the interests of data integrity.

The Polyhedra Relational DBMS products allow tables to be derived from other tables, making it easier for object-oriented applications to store and retrieve the information they need, which has the nice side-effect of improving both performance and overall integrity of the data and the applications that use it.

Download the Full Application Note Here:

Application Note Polyhedra – Table Inheritance

A more pragmatic approach is not trying to parallelize the application, but instead to instantiate the application with its operating system, one instantiation on top of each core, as depicted in the figure.   However, for this to succeed, the application itself must be capable of being partitioned in this way. As an example, take an application that is processing networking traffic. It receives packages via a 1G Ethernet interface, processes the package according to some algorithm, and then sends it out again with the same interface. There is no state shared between the packages in this algorithm. This application could be trivially instantiated and migrated to multicore using a hypervisor. Each core could use its own 1G interface, or if the hardware supports it, the traffic from a single 10G interface could be spread across the cores.

Even if there is some shared state between packages in the algorithm, the same parallel approach describe above works. Assume that the shared state between packages is statistics that are updated frequently but read rarely. This type of shared state is trivially parallelized by introducing per core data, and each core only updates its own per core statistics data. When somebody wants to read the aggregate statistics, all per core data is read and added together. The rest of the applications and operating systems are untouched and has the same characteristics as before.

To summarize, by replicating both the application and the operating system across the multicore, there are many fewer surprises. There are no deadlocks due to moving to an SMP OS, the good old synchronization primitives still work, and the determinism will be the same as before. In summary, there are fewer headaches by replicating the system across a multicore chip, and the focus is on only the parts that truly must be shared between cores. In many cases, a hypervisor-driven approach is the safer and faster way to migrate to multicore.

System consolidation can be achieved much in the same way as with the multicore migration scenario. Take each of the boards and instantiate them on top of the hypervisor with all its applications and operating system together. This case is easier, as there is no shared memory between the boards by design. The only thing that has to be addressed is the communication mechanism between the boards, which now has to work between the guests on the cores. It is often possible to run the same communication mechanism as before, but this will not be efficient from a performance point of view. There is shared memory, or other chip local intra-core messaging mechanisms, that can be used for much faster cross guest communication.

 The Enea Hypervisor ships with an inter process communication mechanism (IPC) called LINX that is location and media transparent with high performance. It works on top of e.g. shared memory, Ethernet,SRIO, and TCP/IP, and could be used for fast inter-board communication in a system consolidation scenario.

 A key property of the hypervisor in this scenario is isolation. This property states that no guests should crash, or otherwise affect the execution of, another guest or the hypervisor. (Note that it is not possible to achieve perfect performance isolation in today’s multicore chips, as the guests share memory and caches at some level.) If one of the boards crash only that board has to be restarted, not every single board in the system. Also, that board cannot crash any other board in the system by trying to write into its memory, or start malicious DMA transfers, because it just cannot reach other board’s memories or DMA circuits. Isolation is important in order to maintain the same failure model as the original system had.

 The same characteristic and failure model as used for isolation are maintained by the hypervisor. Any guest can be restarted independently from one another, and each guest is isolated from the others and can not affect each other’s state. It is also important to have isolation for failure detection and failure containment, but this applies for all use cases.

Learn more about the Enea Hypervisor here.

Why is it necessary to have a hypervisor even on a multicore chip when a designer only wants to execute one operating system per core? Even though the cores in themselves are private to each guest, there are many resources outside the core that are shared between guests. For example, physical memory, interrupt controllers, memory controllers, and external devices such as persistent storage and networking. The reason for this is that the vast majority of multicore chips out there are designed for running one single symmetric multiprocessing (SMP) operating system that takes over the entire socket and not individual OS instances such as in an Asymetric multiprocessing (AMP) system.

In the desktop market, a hypervisor is often referred to as a virtual machine monitor or VMM. A VMM and a hypervisor are really one and the same, although the connotation of a virtual machine monitor is something rather heavy weight but full featured, while a hypervisor signifies something more lean and mean.

Hypervisors exist in two main flavors, type 1 and type 2. Type 1 hypervisors execute right on top of the hardware and have little overhead as they are usually quite small. This also means that they have few services above the bare minimum needed in order to execute and isolate the guests. Type 2 hypervisors, on the other hand, execute on top or within an operating system. Examples of these are KVM in Linux or VmPlayer from VmWare Inc. These are quite feature rich as they can use all the bells and whistles of the host operating system underneath, but are generally slower because the hypervisor is running on top of another operating system instead of directly on the bare metal hardware.  

The Enea Hypervisor is a type 1 hypervisor with regards to performance and the fact that it is executing straight on top of the hardware, but it also has the rich feature set of a type 2 hypervisor that can be used when needed.  Learn more about the Enea Hypervisor here.

Enea has implemented the MCAPI API standard over its existing open source Enea® LINX protocol, thereby offering the market an MCAPI API solution that is interoperable between all nodes, interconnects and OS/RTOS platforms.

You will learn:

• How LINX delivers device, RTOS/OS and interconnect interoperability with MCAPI
• How to develop software with the LINX inter-process communications technology
• Where and how to get the open source MCAPI/LINX implementation to start your multicore project development

Details:

November 9, 2011, 7am or 11am Pacific

CLICK TO REGISTER NOW

 About MCAPI and Enea LINX

The Multicore Communications API (MCAPI) specification, supported and developed by the Multicore Association, captures the basic elements of communication and synchronization that are required for closely distributed (multiple cores on a chip and/or chips on a board) embedded systems. As currently implemented, MCAPI ensures compatibility of application code, but does not guarantee interoperability across MCAPI endpoints or nodes in a system. Enea LINX, a high-performance inter-process communications technology from Enea, already provides a proven and open interoperable protocol across all devices, all interconnects, and all OS/RTOS environments.

Register Today!

Why would you want to do that?

To gain access secure low-risk, low investment access to scalable, highly available clusters.  Low risk means that the service provider can determine its level of investment and exposure in a way that is closely tied to its revenue using an on-demand approach, avoiding mistakes in investment based on forecasts and speculation. Low investment means that the service provider can leverage cloud providers’ investments in infrastructure rather than having to make a large, up-front investment in capital equipment. The service provider can provision a cluster rather than purchase, install, and provision a cluster, resulting in the availability of clusters on demand. The service provider doesn’t need space for equipment, power with which to run the equipment, and cooling for the equipment. Lastly, the target of this discussion, the TEM, doesn’t need to manufacture, ship, and install equipment in the service providers’ central office.

Learn more about the Enea approach in this video.

Unlike other, less proven system management middleware solutions, Enea Element is modular allowing you to implement all of its services or just those that you require for your project.

Element has been used by tier 1s, tier 2s and start ups to deliver off the shelf programmability and reliability in a wide range of communications systems.  More than just a pile of code that you have to hire someone to squeeze into your system, Element is a true off the shelf software solution. 

Learn more about Enea Element here.

Stop by our booth and speak with our technical experts or check out the onsite demo of our TI OMAP-L137/138 solution featuring Enea OSE running on the ARM core and the Enea OSEck running on the TI DSP – all supported by Enea LINX IPC and Enea Optima development tools.

Conny Öhult, Director of Product Management will be on hand to deliver the presentation:

ARM-based Processors in Networking: Runtime Software for Heterogeneous Multicore

Time: 2:30pm – 3:20pm
Location: Ballroom C
Speaker: Conny Ohult, Director of Product Management, ENEA

To achieve the highest level of system integration and performance, next
generation systems for wireless basestations, small cells, gateways and
many other networking applications will be built using a heterogeneous
combination of ARM processors, DSPs and hardware accelerators.
Developers adopting these devices will face a new level of complexity on
the software level. In this presentation we will look into what the
developer will need to overcome the performance, scalability and
ease-of-use issues when adopting these new ARM based devices. Enea’s
platform for heterogeneous SoC include Linux, RTOS, Hypervisor,
Interprocess Communication technology and the middleware and development
tools needed to tie the entire software platform together, all designed
to enable maximum design flexibility, late system partitioning,
application transparency and seamless development and debug experience.

Download the Active Queries White Paper here.

Learn more about Polyhedra here.

Download the Active Queries White Paper here.

Learn more about Polyhedra here.