User manual

Miscellaneous Notes

IO bound application cannot be expected to scale, since they will be largely limited by the

bandwidth of disk IO subsystem and by serialization on the IO device, including serialization

within the device itself and serialization by system locks associated with the device (device

spinlock and fork queue lock) held during IO request processing and also by OpenVMS

processing of interrupts and kernel-mode IO postprocessing that happens on the primary

processor only.

Our IO test application (ST_FILE) performing disk file reading and writing in 512-byte blocks

levels off at maximum scalability level of 1.8 over single processor; whereas for more realistic

applications, reading and writing in longer blocks, saturation will be reached even earlier.

We do not expect VAX MP itself to limit scalability to a significant extent (beyond limitations of

host OS and host machine, as well as inherent serialization within a workflow), however it must

be borne in mind that historical VAX machines existed in configurations with only up to 6 CPUs

maximum, and therefore OpenVMS VAX never historically ran on configurations beyond 6

processors. It was not designed and tuned for scalability to much larger number of processors.

For example, OpenVMS VAX scheduler uses global locking and does not feature per-CPU

scheduling queues with inter-CPU balancing. IO interrupts are processed on primary

processor only. Timer expiration is processed on primary processor only. And so on.

We have not performed VAX MP scalability benchmarking yet. It is nevertheless a preliminary

expectation that for compute-bound workloads with moderate inter-process and inter-

processor interaction VAX MP itself won’t be a significant limiting factor (apart from scalability

limitations of underlying host system).

It should be also borne in mind when running VAX MP on system with hyperthreaded cores that

hyperthreaded core is equivalent in performance not to 2x of non-hyperthreaded core, but

approximately 1.2-1.3x. Thus, for example, assuming single-processor performance estimate of

40 VUPS, rough estimate for cumulative performance of virtual VAX system executed on quad-

core hyperthreaded host processor would be not 320 VUPS, but around 200 VUPS.

Virtual disk file extension (Microsoft Windows)

On Windows, avoid using extension DSK for virtual disk container files and also using any other

file name extensions monitored by Windows System Restore facility. Full list of monitored

extensions can be found in article “Monitored File Name Extensions”.

If System Restore is

enabled, Windows may try to create backup copies of these files in Restore area, causing

simulator to freeze for a long time while the file is being copied by Windows. The easiest way to

avoid the problem is to use extensions such as VDISK, VDSK or VDK that are not on the list of

monitored extensions.

http://msdn.microsoft.com/en-us/library/windows/desktop/aa378870%28v=vs.85%29.aspx