AlphaVM-Free
A commercial Alpha AXP system emulator from EmuVM, the AlphaVM family of system emulators provide a means to emulate members of the Tsunami family of Alpha based systems from Compaq and HP. Mainly targeted at providing a migration option for existing Alpha systems running OpenVMS or Tru64 UNIX, allowing existing applications to be moved to newer, and potentially more efficient, hardware. A free version of AlphaVM (AlphaVM-Free) was offered as an evaluation and hobbyist product complementing the supported commercial offering (AlphaVM-Pro). Apparently due to licence abuse (see The sad state of Alpha emulators (for OpenVMS) - Raymii.org) the free version has been since replaced with a low cost option (AlphaVM-Basic).
To have a look at the emulator's capabilities and how well it manages to run HP Tru64 UNIX, I've setup a legacy AlphaVM-Free system in a Debian Linux 10 (buster) virtual machine and installed HP Tru64 UNIX 5.1B. Since all versions of AlphaVM are related the other versions will show similar behavior, although there is some additional flexibility with tuning the emulation available in the commercial product.
Note that AlphaVM requires the CMPXCHG16B instruction to be available on the host. In my case this meant I had to update the VirtualBox configuration for the Debian Linux 10 host virtual machine to allow access to this instruction (see virtualbox.org: View topic - hot to enable CMPXCHG16B instruction).
Emulated System
AlphaVM-Free emulates a range of systems in the Tsunami family of systems, which were based on the 21272 (Tsunami) and 21274 (Typhoon) chipsets:
- Extreme Performance (XP) workstations:
- Compaq XP900
- Compaq XP1000
- Departmental Server (DS):
- Compaq DS10, DS10L
- Compaq DS20, DS20E, DS20L
- Enterprise Server (ES):
- Compaq ES40
The DS and ES lines were available in server (AlphaServer) and workstation (AlphaStation) enclosures, the XP line only had a workstation. The the Tsunami/Typhoon chipsets were also used in the AlphaPC 264DP board and its derivatives (e.g. API UP2000 and UP2000+), but an AlphaVM system profile is not provided for those systems. The high-end Global Server (GS) series of the same period utilized custom chipsets, and are part of the TurboLaser and Wildfire families, rather than the Tsunami family.
For this exploration I've selected a DS10 system with an EV67. For comparison the equivalent physical system configuration (as sold by Compaq) would be:
Compaq AlphaServer DS10 67/600:
- CPU: Alpha 21264A (EV67) at 616 MHz
- RAM: 256 MiB to 2 GiB
- Network: 2 10/100 ethernet - Tulip 21143 (DE500)
- Disk controller:
- built-in dual IDE (provided by Acer Labs 1543C)
- SCSI option: Ultra2 (KZPCA-AA; NCR53c895), Ultra3 (KZPEA-DB; AIC-7899)
- Misc.: Acer Labs 1543C providing: dual IDE, Floppy, USB, 2 serial, 1 parallel, keyboard & mouse (PS/2)
AlphaVM uses substitutions for some of the standard configuration hardware, and I want to see how some of the alternative device options turn out, so the emulated system looks more like:
- CPU: Alpha 21264A (EV67) at 616 MHz
- RAM: 1 GiB
- Network interfaces:
- DE500 10/100 Mb/s ethernet (Tulip 21143)
- DE435 10 Mb/s ethernet (Tulip 21040)
- Disk controller:
- SCSI: QLogic ISP 1020 SCSI controller with 22 GB, 2 GB and CD-ROM drives
- Misc.: 2 serial, 1 parallel
The AlphaVM documentation doesn't say much about the additional built-in devices, so I'm assuming they are absent.
Emulator Command
AlphaVM uses a configuration file for the emulated system specification, and this is simply referenced in the command-line:
$ alphavm_free config.emu
The config.emu file I'm using is:
system {
type = ds10_616;
reported_type = default;
num_cpus = 1;
ssn = 'EmuVM-00-000-001';
interval_clock_freq = 1000;
memory {
size = 1024;
}
cpu {
server = basic;
jit {
async = yes;
}
}
serial com1 {
server = socket;
port = 3000;
}
scsi_controller qla0 {
scsi_id = 7;
}
scsi_disk dka0 {
scsi_bus = 0;
scsi_id = 0;
scsi_lun = 0;
file = 'disk01.dd';
caching = no;
write_through = yes;
}
scsi_disk dka1 {
scsi_bus = 0;
scsi_id = 2;
scsi_lun = 0;
file = 'disk02.dd';
caching = no;
write_through = yes;
}
scsi_cdrom iso {
scsi_id = 4;
file = 'ISO/tru64-cd1.iso';
}
ether eth0 {
type = dec21143;
server = dummy;
mac_address = 0x08002B000001;
}
ether eth1 {
type = dec21040;
server = dummy;
mac_address = 0x08002B000002;
}
}
Note: this system profile (ds10_616) always provides two ethernet interfaces, which by default are dummy devices. Here this default is overridden to give us one each of the two supported types of adapter (DE500 & DE435) with distinct MAC addresses.
Unlike a real DS10, where the supplied CD-ROM drive is on an IDE bus, the only option here is to configure the CD-ROM drive as a SCSI device, in this case mapped to an ISO image of CD 1 of the Tru64 installation disk set.
HP Tru64 UNIX
The main UNIX for Alpha based systems, Tru64 UNIX (Wikipedia), was derived from OSF/1 (Wikipedia) and had a number of name changes thoughout its life-time:
- DEC OSF/1 AXP
- Digital UNIX
- Compaq Tru64 UNIX
When Compaq merged with HP, documentation and marketing materials were updated to use HP Tru64 as the name, but the operating system retained mentions of the Compaq name in order to promote compatibility.
System Information
So lets see what the firmware and operating system have to say about emulated platform.
SRM Firmware
The AlphaVM-Free version of the SRM firmware doesn't provide the full capabilities of the SRM console on a real DS10, however it does provide the core "show devices" command for reporting potential boot devices:
>>> show devices pka SCSI Controller dka0 SCSI 0 14 0 0 0 0 0 dka200 SCSI 0 14 0 0 200 0 0 dka400 SCSI 0 14 0 0 400 0 0 ewa MOP 0 9 0 0 0 3 0 (08:00:2b:00:00:01) ewb MOP 0 11 0 0 0 3 0 (08:00:2b:00:00:02)
Here we see the SCSI controllers (pka & pkb), their disks (dka0 & dka200) and the SCSI CD-ROM drive (dka400), and the network interfaces (ewa & ewb). The reported device names (see SRM Device Naming) match the expected names of the devices configured for the system.
uname
System version and architecture information:
# uname -a OSF1 alvm-tru64 V5.1 2650 alpha
Breaking this down: OSF1 is the operating system name for Tru64 and its predecessors, the release is V5.1, and the version 2650, which is the 'B' update (and its subsequent patches), running on an Alpha.
sizer
Reports on the system and/or kernel. In this case we use:
- -v to get the operating system version string
- -c to get the CPU type
- -implver to get the processor family name
So lets see what we have...
# sizer -v Compaq Tru64 UNIX V5.1B (Rev. 2650); Wed Jun 16 14:14:34 BST 2021 # sizer -c cpu "DEC6600" # sizer -implver EV6
The operating system version string confirms this is Tru64 5.1B, with a recently built kernel.
The CPU module is a "DEC6600", this identifier is associated with the DS10, DS20 and ES40 systems.
The processor family is EV6 which is correct for the Alpha 21264 chip and its derivatives (Wikipedia). Although the specified DS10 model should have the improved EV67 rather than a plain EV6.
psrinfo
Report processor information:
# psrinfo -v Status of processor 0 as of: 06/16/21 14:44:35 Processor has been on-line since 06/16/2021 14:15:24 The alpha EV6.7 (21264A) processor operates at 617 MHz, has a cache size of 1048576 bytes, and has an alpha internal floating point processor.
For our emulated DS10 model we expect one Alpha EV67 running at 616 MHz, and that is what the system reports.
hwmgr
Report hardware information:
# hwmgr view devices
HWID: Device Name Mfg Model Location
------------------------------------------------------------------------------
3: /dev/dmapi/dmapi
4: /dev/scp_scsi
5: /dev/kevm
26: /dev/disk/dsk0c EmuVM HD image bus-0-targ-0-lun-0
27: /dev/disk/dsk1c EmuVM HD image bus-0-targ-2-lun-0
28: /dev/disk/cdrom0c EmuVM CDROM ISO image bus-0-targ-4-lun-0
29: /dev/random
30: /dev/urandom
# hwmgr view hierarchy
HWID: hardware hierarchy
-------------------------------------------------------------------------------
1: platform AlphaServer DS10 616 MHz
2: cpu CPU0
6: bus pci0
7: connection pci0slot7
15: bus isa0
16: connection isa0slot1
17: serial_port tty00
18: connection isa0slot2
19: serial_port tty01
20: connection isa0slot3
21: parallel_port lp0
9: connection pci0slot9
22: network tu0
11: connection pci0slot11
23: network tu1
13: connection pci0slot14
24: scsi_adapter isp0
25: scsi_bus scsi0
26: disk bus-0-targ-0-lun-0 dsk0
27: disk bus-0-targ-2-lun-0 dsk1
28: disk bus-0-targ-4-lun-0 cdrom0
Here we see the emulated disks give a fingerprint for the emulator with the "EmuVM" manufacturer string.
So the system is identified as an AlphaServer DS10, as expected, with one CPU, two SCSI hard disks and a CD-ROM, 2 serial ports, 1 parallel port and a two Tulip based network interfaces. As expected for the emulated system configuration.
On a real DS10 system we would also expect to see the other built-in devices: keyboard, mouse, floppy disk controller, IDE controller and USB. However since we can't configure these for use with AlphaVM it is unsurprising they are not implemented in the emulated system.
vmstat
Virtual memory information with some additional physical memory information:
# vmstat -P
Total Physical Memory = 1024.00 M
= 131072 pages
Physical Memory Clusters:
start_pfn end_pfn type size_pages / size_bytes
0 256 pal 256 / 2.00M
256 131072 os 130816 / 1022.00M
Physical Memory Use:
start_pfn end_pfn type size_pages / size_bytes
256 289 scavenge 33 / 264.00k
289 1070 text 781 / 6.10M
1070 1213 data 143 / 1.12M
1213 1441 bss 228 / 1.78M
1441 1637 kdebug 196 / 1.53M
1637 1644 cfgmgmt 7 / 56.00k
1644 1645 locks 1 / 8.00k
1645 1659 pmap 14 / 112.00k
1659 2265 unixtable 606 / 4.73M
2265 2289 logs 24 / 192.00k
2289 5302 vmtables 3013 / 23.54M
5302 131072 managed 125770 / 982.58M
============================
Total Physical Memory Use: 130816 / 1022.00M
Managed Pages Break Down:
free pages = 109057
active pages = 4320
inactive pages = 0
wired pages = 7284
ubc pages = 5142
==================
Total = 125803
WIRED Pages Break Down:
vm wired pages = 1044
ubc wired pages = 0
meta data pages = 3882
malloc pages = 1131
contig pages = 695
user ptepages = 393
kernel ptepages = 132
free ptepages = 7
==================
Total = 7284
This reports the expected 1 GiB memory from the emulator configuration.
System Boot Record
Kernel messages from the boot process:
# uerf -R -r 300
uerf version 4.2-011 (122)
********************************* ENTRY 1. *********************************
----- EVENT INFORMATION -----
EVENT CLASS OPERATIONAL EVENT
OS EVENT TYPE 300. SYSTEM STARTUP
SEQUENCE NUMBER 1.
OPERATING SYSTEM DEC OSF/1
OCCURRED/LOGGED ON Wed Jun 16 15:28:06 2021
OCCURRED ON SYSTEM alvm-tru64
SYSTEM ID x000B0022
SYSTYPE x00000000
MESSAGE Alpha boot: available memory from
_0x296c000 to 0x40000000
Compaq Tru64 UNIX V5.1B (Rev. 2650);
_Wed Jun 16 14:14:34 BST 2021
physical memory = 1024.00 megabytes.
available memory = 982.57 megabytes.
using 3882 buffers containing 30.32
_megabytes of memory
Firmware revision: 13.0-0
PALcode: UNIX version 1.62-1
AlphaServer DS10 616 MHz
config_cpus: Could not find config
_tree entry for CPU0
pci0 (primary bus:0) at nexus
isa0 at pci0
ace0 at isa0
ace1 at isa0
lp0 at isa0
tu0: DECchip 21143: Revision: 3.0
tu0: auto negotiation capable device
tu0: no SROM info for selected media
tu0 at pci0 slot 9
tu0: DEC TULIP (10/100) Ethernet
_Interface, hardware address:
_08-00-2B-00-00-01
tu0: auto negotiation off: selecting
_100BaseTX (UTP) port: full duplex
tu1: DECchip 21040: Revision: 2.0
tu1 at pci0 slot 11
tu1: DEC TULIP (10Mbps) Ethernet
_Interface, hardware address:
_08-00-2B-00-00-02
tu1: console mode: selecting 10BaseT
_(UTP) port: full duplex
isp0 at pci0 slot 14
isp0: QLOGIC ISP1020B - Differential
_Mode
isp0: Firmware revision 7.63 (loaded
_by console)
scsi0 at isp0 slot 0 rad 0
Created FRU table binary error log
_packet
kernel console: ace0
dli: configured
NetRAIN configured.
Random number generator configured.
ATM Subsystem configured with 1
_restart threads
ATMUNI: configured
ATMSIG: 3.x (module=uni3x) configured
ILMI: 3.x (module=ilmi) configured
ATM IP: configured
ATM LANE: configured.
ATM IFMP: configured
While not the prettiest format, this does cover what happened during boot. There is a lot of information in here, some of which is redundant with earlier information, so I'll only comment on some highlights.
The two network adapters are identified here showing the "tu0: DECchip 21143" (DE500) and "tu1: DECchip 21040" (DE435). As is the SCSI controller "isp0: QLOGIC ISP1020B"
Benchmark
Since this is an emulated machine an obvious question is, how well does it perform compared to the real thing? To find out we're going to need a benchmark.
BogoMips
The BogoMips (Wikipedia) pseudo-benchmark has a behavior where the score is related to the processor clock speed, and has an easily available collection of results from a range of systems (see BogoMips mini-Howto). This is helpful in this case since the performance of processors of this era typically scaled with clock speed. So let's get some results using the standalone BogoMips 1.3 program and see what it says:
> ./bogo.sh Calibrating delay loop.. ok - 74.00 BogoMips Calibrating delay loop.. ok - 76.00 BogoMips Calibrating delay loop.. ok - 78.00 BogoMips Calibrating delay loop.. ok - 76.00 BogoMips Calibrating delay loop.. ok - 76.00 BogoMips
On an Alpha 21264 (EV6) the Linux BogoMips result is approximately equal to twice the processor clock speed, which would suggest the emulated machine is very slow (Mhz = BogoMips / 1.99 => 80 / 1.99 = 40.2 MHz) compared to the real hardware.
OpenSSL
One of the provided benchmarks for AlphaVM (Benchmarks - EmuVM) uses OpenSSL to get a performance measure. So lets see how that compares:
> openssl speed md5
Doing md5 for 3s on 8 size blocks: 157920 md5's in 2.83s
Doing md5 for 3s on 64 size blocks: 86312 md5's in 2.85s
Doing md5 for 3s on 256 size blocks: 37151 md5's in 2.82s
Doing md5 for 3s on 1024 size blocks: 11254 md5's in 2.85s
Doing md5 for 3s on 8192 size blocks: 1506 md5's in 2.85s
OpenSSL 0.9.6g [engine] 9 Aug 2002
built on: Thu Aug 15 02:59:23 EDT 2002
options:bn(64,64) md2(int) rc4(ptr,int) des(idx,cisc,4,long) blowfish(idx)
compiler: cc -DTHREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DNO_ASM -DNO_IDEA -DNO_RC5 -DNO_HW_KEYCLIENT -pthread -std1 -O4 -readonly_strings
The 'numbers' are in 1000s of bytes per second processed.
type 8 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
md5 445.89k 1938.23k 3376.56k 4043.54k 4328.83k
> openssl speed rsa
Doing 512 bit private rsa's for 10s: 598 512 bit private RSA's in 9.48s
Doing 512 bit public rsa's for 10s: 8019 512 bit public RSA's in 9.50s
Doing 1024 bit private rsa's for 10s: 135 1024 bit private RSA's in 9.50s
Doing 1024 bit public rsa's for 10s: 2633 1024 bit public RSA's in 9.50s
Doing 2048 bit private rsa's for 10s: 23 2048 bit private RSA's in 9.73s
Doing 2048 bit public rsa's for 10s: 776 2048 bit public RSA's in 9.43s
Doing 4096 bit private rsa's for 10s: 4 4096 bit private RSA's in 11.30s
Doing 4096 bit public rsa's for 10s: 216 4096 bit public RSA's in 9.50s
OpenSSL 0.9.6g [engine] 9 Aug 2002
built on: Thu Aug 15 02:59:23 EDT 2002
options:bn(64,64) md2(int) rc4(ptr,int) des(idx,cisc,4,long) blowfish(idx)
compiler: cc -DTHREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DNO_ASM -DNO_IDEA -DNO_RC5 -DNO_HW_KEYCLIENT -pthread -std1 -O4 -readonly_strings
sign verify sign/s verify/s
rsa 512 bits 0.0159s 0.0012s 63.1 844.1
rsa 1024 bits 0.0704s 0.0036s 14.2 277.2
rsa 2048 bits 0.4232s 0.0122s 2.4 82.3
rsa 4096 bits 2.8250s 0.0440s 0.4 22.7
The relevant figures are for comparison with the published results are:
- OpenSSL speed MD5 8,192 bytes: 4,328.83k
- OpenSSL speed RSA 4,096 bytes sign/s: 0.4
- OpenSSL speed RSA 4,096 bytes verify/s: 22.7
These figures are much lower than the published results, however this is using AlphaVM-Free, which doesn't have access to the higher performance CPU emulations in AlphaVM-Pro, which was used for the published benchmark. Comparing with the real DS10 system in the benchmark result it would appear that this emulated machine is around 1/10 of the performance.
Thoughts
AlphaVM-Free runs HP Tru64 UNIX very well, and although the performance is a bit less than expected it should be adequate for most hobbyist purposes. However since it is no longer available, the replacement AlphaVM-Basic option is worth a look for these roles. For the types of workloads expected for system migrations, it is evident that the AlphaVM-Pro product would be a much better option for commercial applications.
The estimated 1/10 of a real DS10 gives us something to work with regarding comparisons with other Alpha systems and emulations. Certainly the performance seen here for Tru64 UNIX is comparable with the FreeAXP system emulator from Migration Specialties International, Inc. (see HP Tru64 on FreeAXP - System Information). But the availability of more memory and more hardware configuration options placed AlphaVM-Free ahead in the free Alpha emulation stakes.
Further Sources
- AlphaVM for Windows: User Manual
- [PDF] AlphaVM for Linux User Manual - Free Download PDF
- Running Tru64 UNIX inside a VM for Metasploit testing | Astr0baby's not so random thoughts _____ rand() % 100;
- Unix OS archaeology – Tru64 UNIX part 2 | Astr0baby's not so random thoughts _____ rand() % 100;
- Tru64 5.1B Unix and Oracle 9i infosec exercise | Astr0baby's not so random thoughts _____ rand() % 100;
- virtualbox.org: View topic - hot to enable CMPXCHG16B instruction
- DEC GETS ‘COMPAQ-TED’ AT DECUS
No comments:
Post a Comment