[Info-vax] Alpha emulator for OSX

[Chris Scheers]

IanD wrote:
> 
> I was speaking with someone who performs VMS emulator installs. They
did a project for let's say a large government entity that likes to blow
up things and they had to make specific changes in the Vax emulator to
slow it down as the other systems it interfaced with required specific
inputs at specific times from the Vax as part of it's simulation package.


There is indeed lots of crap timing code out there.  I'm constantly 
shocked (although no longer surprised) by the software loops I see doing 
timing.

I analyzed one system and found that they were starting a DMA on a 
device, spinning in a software loop for some period, then aborting the 
DMA.  Then they checked to see how many words of the DMA were actually 
transferred.  It it wasn't exactly what they were expecting, they failed 
the hardware.

Not only was this test tightly coupled to specific hardware (even a 
different model CPU board could cause it to fail), there was no 
documentation or specifications from which this requirement could be 
derived.

When I pointed out to the customer the uselessness of this test and that 
it could fail on a different rev of the real hardware, their response 
was that it had always been done this way and the emulator had to pass 
this test.

Many, many clients do not want an emulator that runs faster than the 
hardware it is replacing.  They want an emulator that runs EXACTLY the 
same as the original hardware.  Many of these systems are involved in 
some sort of control environment.



> I/O is another matter. We emulated our testing environment onto a
commercial emulator and immediately ran into problems. Why? Because
the system had one cpu and a bunch of slow RZ disks. When it was
emulated, the I/O ran so dam fast that the cpu immediately hit 100%
for any task that was run!

Throughput was quicker but a 'slow' system became an immediate complaint
of users because the system became immediately cpu bound.  It's something
they don't tell you when you go down the emulator route, that you may see
bottlenecks pop up where you had none before


You may see bottlenecks move or popup whenever you change hardware 
configuration/performance, emulated or otherwise.

I had a client that had high priority tasks that did disk updates. 
Because the disk was so slow on the original hardware, these high 
priority tasks did not cause problems.

When they went to emulation, the emulated disk was fast enough that the 
high priority disk updates became CPU bound, starving out the normal users.

The solution was to slow down the emulated disks.  It was not necessary 
to get as slow as the original disks, but a balance had to be found.

(Yes, I know that a better solution would have been to fix the original 
code to work correctly, but the places looking for emulation are 
generally locked into their existing software for various reasons. 
Quite often changes are not an option.)

Because of issues like this, good emulators have all sorts of tuning 
knobs you can adjust.

-- 
-----------------------------------------------------------------------
Chris Scheers, Applied Synergy, Inc.

Voice: 817-237-3360            Internet: chris at applied-synergy.com
   Fax: 817-237-3074