Hi Zane,
Firstly, thank you all for the quick responses. And yes I made a mistake in
calculating the relative (raw) CPU performance of my VAXstation vs Raspberry
Pi; the Pi is indeed only 12 times the clock speed of the VAXstation.
Don't forget SIMH is emulating a lot more than just the CPU, it also has to
emulate all the rest of the hardware that makes up a VAX.
Indeed, although where it's slowest appears to be floating point. Which has
got me thinking about my choice of emulated VAX, or about the rigour of the
emulation. More on this in a moment.
My Raspberry Pi 2 clocks in at about 1.6 VUPS, my ESXI host is a i7-3770
CPU @ 3.40GHz (which is starved for RAM), SIMH/VAX on a VM running on it
clocks in at about 34.6 VUPS. I have a i5-3470 @ 3.2Ghz and SIMH runs at
about 31.6 VUPS. If you have a top of the line, current i7, you might be
able to get close to the speed of your VAXstation 4000/96.
Interesting. One of the reasons I went for the RPi solution was to keep
power consumption to a minimum but given the VAXstation consumed about 100W
I could obviously go to a reasonably powered server to get the performance.
Instead of starting SIMH like this:
$ ./vax < vax.ini
Try:
$ ./vax vax.ini
I will. I might also experiment with the SIMH "expect" functionality.
All my VMS systems are using Telnet right now, as I don't have any VMS
system running a modern version of SSH. I've also not managed to get
DECwindows to work right with any X-Windows on my current systems (it works
fine with my SGI O2). This is one of the reasons I'm considering running a
physical VMS system as a desktop.
In my experience with recent X11 servers (anything released in the last
several years) the only permitted clients are those running on the local
host or via an SSH session with X-Auth forwarding enabled. I suspect it's
possible to enable less secure access controls but it looks like you have to
jump through hoops to get there.
You bring up a very good point on the licensing though. I'm not sure what
to suggest there. :-(
The license wouldn't be an issue if the SET CPU MODEL command worked.
And in response to Timothe Litte,
Two issues have been discussed before.
The boot failures are being worked by Mark - they're some timing issue
having to do with the fact that SimH is faster than the hardware. They
seem to be a heisenbug. He's recently added instrumentation.
It just seems curious that taking the SIMH commands from a file rather than
the keyboard should make any difference. The emulated VAX isn't even
started at that point.
The SSH startup isn't compute bound so much as entropy limited. This
was discussed a while ago, but I don't recall the final outcome. Check
the archives.
I recall some of that discussion. I think the SSH server is having to do a
whole lot of math to come up with sufficient entropy and no doubt that's a
lot of floating point.
It occurred to me that the emulation I'm running is a -3900 series machine
which if memory serves, did not have an FPU. Meaning all those VAX floating
point operations are being emulated twice -- once by the VAX and once by
SIMH. Is that correct? If so I wonder if the emaulation could be tweaked
to behave as if the emulated machine has an FPU.
The 4000/96 would be a NVAX or NVAX+.� It would require more license
units than the 3900, so I'm somewhat surprised that you're having
issues. But LMF has lots of ways to evaluate licenses. The SID
register reflects the CPU type; SYS_TYPE has the licensing bits. The
SID determines which VMS CPULOA is loaded - this is what I/O buses are
supported, machine check format - you can't change it without a lot more
grief. The SYS_TYPE bits are the workstation vs. server. There's SimH
support for that.
There's a SIMH "SET CPU MODEL" command which supposedly lets it switch
between MicroVAX3900 and VAXserver3900, but the command has no effect and
the machine always boots as a VAXserver -- which required the somewhat
obscure availability table code "B" licence. (I've never seen one in the
wild, and I have a folder full of original VAX licence PAKs.)
FWIW, on this machine the SID = 0x0A000006 and SHOW CPU says:
ERIC, a VAXserver 3900 Series
Multiprocessing is DISABLED. Uniprocessing synchronization image loaded.
PRIMARY CPU = 00
Active CPUs: 00
Configured CPUs: 00
Thanks,
Jeremy Begg
On Jul 30, 2018, at 3:57 PM, Jeremy Begg <jer...@vsm.com.au> wrote:
Hi,
A while ago the power supply in my VAXstation 4000/96 died and rather than
fix it I decided to move it to a Raspberry Pi 3.
The VAXstation has a 100MHz CPU and the RPi has a 1.2GHz CPU - about 120
times faster. Yet the performance of SIMH basically sucks, especially when
logging in to the emulated VAX via SSH.
On the real VAXstation, establishing an SSH sesison was slow -- it would
take the better part of a minute -- but once established it was very usable
and quite capable of running a DECterm to an X11 display on a remote PC over
an SSH tunnel.
On the Raspberry Pi the SSH session establishment takes several minutes and
trying to run a DECterm is painful to say the least. I was hoping that the
RPi's much faster CPU would compensate for the emulation overhead,
particularly on a very CPU-intensive task like SSH session establishment, so
this result is rather disappointing.
I could perhaps put up with those issues but there two other, more
fundamental problems when starting the simulation.
The first one is, the emulation can't be started automatically; I have
to run it interactively in a terminal window. If I try to automate the
startup using, for example
$ ./vax < vax.ini
the VAX console boot ROM fails a self test and refuses to boot into VMS.
If I type the commands from vax.ini by hand, it works fine.
A similar issue occurs if I try to load the boot console NVR from a file:
the VAX console boot ROM fails its self-test and won't boot VMS.
The second problem is that the simulated VAX is *always* a VAXserver 3900.
Trying to SET CPU MODEL=MicroVAX just doesn't work, so my VAX-VMS licence
PAK's availability table code don't suit the machine any more.
The SIMH version is currently
MicroVAX 3900 simulator V4.0-0 Beta git commit id: 733ac0d9
I tried downloading the latest from Github (git commit id: 8077d4de) but it
didn't fix the startup issues so I haven't persisted with it.
Before starting this exercise I had read several reports of people
successfullly using Raspberry Pi to run an emulated VAX so I have to think
something is very broken in my RPi environment, but I'm not sure what I
should be looking for.
FWIW the Raspberry Pi is running
Linux pieric 4.14.52-v7+ #1123 SMP Wed Jun 27 17:35:49 BST 2018 armv7l GNU/Linux
and the file /etc/os-release is:
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/";
SUPPORT_URL="http://www.raspbian.org/RaspbianForums";
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs";
SIMH was built with "gcc (Raspbian 6.3.0-18+rpi1+deb9u1) 6.3.0 20170516".
Here is the full SHOW VERSION output:
sim> show version
MicroVAX 3900 simulator V4.0-0 Beta
Simulator Framework Capabilities:
64b data
64b addresses
Threaded Ethernet Packet transports:PCAP:TAP:NAT:UDP
Idle/Throttling support is available
Virtual Hard Disk (VHD) support
RAW disk and CD/DVD ROM support
Asynchronous I/O support (Lock free asynchronous event queue)
Asynchronous Clock support
FrontPanel API Version 5
Host Platform:
Compiler: GCC 6.3.0 20170516
Simulator Compiled as C arch: ARM (Release Build) on Nov 9 2017 at
08:04:00
Memory Access: Little Endian
Memory Pointer Size: 32 bits
Large File (>2GB) support
SDL Video support: No Video Support
RegEx support for EXPECT commands
OS clock resolution: 1ms
Time taken by msleep(1): 1ms
OS: Linux pieric 4.14.52-v7+ #1123 SMP Wed Jun 27 17:35:49 BST 2018
armv7l GNU/Linux
git commit id: 733ac0d9
The later version (which I'm not running because it didn't fix the startup
issues) is:
sim> show version
MicroVAX 3900 simulator V4.0-0 Current
Simulator Framework Capabilities:
64b data
64b addresses
Threaded Ethernet Packet transports:PCAP:TAP:NAT:UDP
Idle/Throttling support is available
Virtual Hard Disk (VHD) support
RAW disk and CD/DVD ROM support
Asynchronous I/O support (Lock free asynchronous event queue)
Asynchronous Clock support
FrontPanel API Version 12
Host Platform:
Compiler: GCC 6.3.0 20170516
Simulator Compiled as C arch: ARM (Release Build) on Jun 17 2018 at
21:12:47
Memory Access: Little Endian
Memory Pointer Size: 32 bits
Large File (>2GB) support
SDL Video support: No Video Support
RegEx support for EXPECT commands
OS clock resolution: 1ms
Time taken by msleep(1): 1ms
OS: Linux pieric 4.14.52-v7+ #1123 SMP Wed Jun 27 17:35:49 BST 2018
armv7l GNU/Linux
git commit id: 8077d4de
git commit time: 2018-06-17T08:37:08+02:00
Thanks,
Jeremy Begg
+---------------------------------------------------------+
| VSM Software Services Pty. Ltd. |
| http://www.vsm.com.au/ |
|---------------------------------------------------------|
| P.O.Box 402, Walkerville, | E-Mail: jer...@vsm.com.au |
| South Australia 5081 | Phone: +61 8 8221 5188 |
|---------------------------| Mobile: 0414 422 947 |
| A.C.N. 068 409 156 | FAX: +61 8 8221 7199 |
+---------------------------------------------------------+
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
