Emulation of hardware platforms

This information is intended to help you understand the emulation process itself and so be able to make a better informed decision about how applicable an emulator might be to your specific situation. It is not trying to present emulators as either a good thing or as a bad thing - they can be either depending upon your specific circumstances, workloads and availability requirements.

There can be issues with availability as your application is now completely dependent on the underlying operating system and the physical hardware platform. There can be issues with the response time aspects of performance, especially in real-time control system environments. There can be issues with hardware support for I/O devices.

In mission-critical environments the issues of certification and testing becomes very important. You cannot just move to an emulated machine without thorough validation and testing of the entire underlying platform. Do not underestimate the time, effort and cost involved in that process. Sometimes you’re better off sticking with the hardware you know and trust, then building a modern replacement system to smoothly take over from it when you have an opportunity to make controlled changes.

Creating a software emulation of a complex system like a VAX or Alpha is a considerable technical achievement. Software emulation requires a software representation of the instruction set, plus a software representation of the system infrastructure, such as memory and the I/O devices. That software representation then runs on top of another operating system and physical hardware platform. The success of the emulated system is dependent on behavioural characteristics of the entire underlying platform.

Emulators mimic the original hardware architecture and process the instructions and data of the original software as though they were the real thing. It’s a much slower process in that a lot more machine instructions get executed, but because of the much greater clock speeds of modern machines they can actually deliver better performance that the original hardware. The trick to making an emulator work well is configuring it to look like the original system, including all the I/O devices. The aim is that the original operating system and application software, plus your data, remain unchanged.

Performance is determined by three main factors: bandwidth, which determines throughput; latency, which determines response times; and jitter (or variation in latency over time), which affects predictability of response time. In most cases jitter and latency are more important than bandwidth. An emulator will generally have worse jitter and latency than the original hardware, simply because of all the abstraction layers that you have to go through in order to reach the physical hardware.

Remember that the system management requirements for OpenVMS will not go away. If anything you need to have a better understanding of the overall system in order to make it perform well and to be able to diagnose problems. If you need help then please ask us. We'll do our best to help you.