[Simh] VAX emulation issues on Raspberry Pi
Jeremy Begg
jeremy at vsm.com.au
Tue Jul 31 01:31:11 EDT 2018
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 <jeremy at 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: jeremy at 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 at trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
More information about the Simh
mailing list