FreeAXP
Migration Specialties International, Inc. provide a services for the maintenance and migration of OpenVMS and Tru64 operating system environments. Part of their offering uses system emulation to provide an option to migrate from aging hardware on to modern systems. As an evaluation and hobbyist tool, they also provide a free version of their system emulator system: FreeAXP which emulates a DEC Alpha (AXP) based AlphaServer 400 with the specification:
- RAM: 32MB to 128MB
- Up to 7 SCSI disks
- Up to 2 network interfaces
- 2 serial ports (used for system console)
- Capable of running OpenVMS or Tru64
So having downloaded and installed the emulator, I've configured a emulated system for testing with Tru64:
- CPU: a DECchip 21064 (EV4) Alpha processor
- RAM: 128 MB
- SCSI controller: KZPAA (53c810) - narrow SCSI, max. 7 devices
- Id 0: RZ40L SCSI Hard disk - 8 GB
- Id 6: RRD42 SCSI CD-ROM drive - mapped to system optical drive
- Network interface: DE500 (21143)
FreeAXP uses a version of the SRM firmware from the AlphaServer 400, which can tell us a bit about the system before we install an operating system.
SRM System Firmware
Since FreeAXP uses a full version of the SRM firmware (Wikipedia) we can use SRM commands to get information about the hardware in the system and about operating system support. Information about the available SRM commands can be found in appendix "A: Console Commands" in the "Digital AlphaServer™ 400 Series: User Information" manual (PDF).
show version
Firmware version:
>>>show version version V7.0-9 Mar 18 1999 13:25:37
Checking the AlphaServer 400 firmware on the HP FTP site, the latest version available there provides SRM v7.0, which according to the documentation supports: OpenVMS 6.2, 7.0, 7.1, & 7.2; and Digital UNIX 3.2 and 4.0. The system firmware also included ARC 4.58 for running MS Windows NT 3.51 or 4.0. However the documentation is from March 1999, before the release of Compaq Tru64 5.0 in July 1999. All the AlphaServer systems were supported by Tru64 through to the last release of HP Tru64 5.1B-6 in October 2010. The AlphaServer 400 was by OpenVMS through to OpenVMS 8.2 released Feb 2005.
While the emulator's limited hardware selection renders it a bit moot, later versions of the firmware also provide a wider range of hardware support, in particular for graphics adapters, network interfaces and disk controllers. On real hardware this makes itself felt when looking for devices that can be used for booting and supported graphics adapters.
show memory
Report memory configuration:
>>>show memory
128 Meg of System Memory
Bank 0 = 64 Mbytes(32 MB Per Simm) Starting at 0x0
Bank 1 = 64 Mbytes(32 MB Per Simm) Starting at 0x4000000
Bank 2 = No Memory Detected
This is consistent with the required configuration for 128 MiB in an AlphaServer 400.
show device
Report storage and network devices:
>>>show device dka0.0.0.6.0 DKA0 RZ40L 8203 dka600.6.0.6.0 DKA600 RRD42 4.5d dva0.0.0.0.1 DVA0 ewa0.0.0.11.0 EWA0 0A-00-27-00-00-0F pka0.7.0.6.0 PKA0 SCSI Bus ID 7
These devices are:
- PKA0 - SCSI controller (SCSI id 7)
- DKA0 - first SCSI disk (SCSI id 0)
- DKA600 - sixth SCSI disk (SCSI id 6)
- DVA0 - first floppy disk drive
- EWA - first ethernet controller - DEC Tulip chipset based (e.g. DE500)
For more information about SRM device names see SRM Device Naming. Since the device id is needed to run other commands (e.g. boot), this is very commonly used, and often abbreviated to things like "sho dev", "sh dev" or even "sh d".
show pal
Details of the PALcode (Wikipedia) included in the firmware:
>>>show pal pal VMS PALcode V5.56-2, OSF PALcode X1.46-2
So the firmware provides PALcode for OpenVMS and DEC OSF/1 / Digital UNIX / Compaq Tru-64 / HP Tru64. The OSF PALcode is also used by Linux, NetBSD and OpenBSD.
show config
Report the system configuration:
>>>show config
Firmware
SRM Console: V7.0-9
show_arc: Can't find Flash Rom containing ARC console.
PALcode: VMS PALcode V5.56-2, OSF PALcode X1.46-2
Serial Rom: V4.6
Diag Rom: V1.7
Processor
DECchip (tm) 21064-3 166Mhz 512KB Cache
MEMORY
128 Meg of System Memory
Bank 0 = 64 Mbytes(32 MB Per Simm) Starting at 0x0
Bank 1 = 64 Mbytes(32 MB Per Simm) Starting at 0x4000000
Bank 2 = No Memory Detected
PCI Bus
Bus 00 Slot 06: NCR 810A Scsi Controller
pka0.7.0.6.0 SCSI Bus ID 7
dka0.0.0.6.0 RZ40L
dka600.6.0.6.0 RRD42
Bus 00 Slot 07: Intel SIO 82378
Bus 00 Slot 11: DE500-BA Network Controller
ewa0.0.0.11.0 0A-00-27-00-00-0F
ISA
Slot Device Name Type Enabled BaseAddr IRQ DMA
0
0 MOUSE Embedded Yes 60 12
1 KBD Embedded Yes 60 1
2 COM1 Embedded Yes 3f8 4
3 COM2 Embedded Yes 2f8 3
4 LPT1 Embedded Yes 3bc 7
5 FLOPPY Embedded Yes 3f0 6 2
The AlphaServer 400 system firmware contained both SRM and AlphaBIOS (ARC) allowing the system to switch between them if needing to run MS Windows NT for Alpha. Since MS Windows support was dropped back in 1999, during the development of MS Windows 2000, and few applications were created specifically for the Alpha version of MS Windows NT, it is unsurprising that FreeAXP has omitted the ARC firmware need.
The processor is confirmed to be an Alpha 21064 (EV4) chip, I'm assuming the '-3' suffix relates to a processor design revision which didn't involve a production process change. The DECchip name was use by DECs semiconductor business.
The installed KZPAA SCSI controller lets us know that it is NCR 810A (53c810a) based, and the model is reported for the DE500-BA ethernet adapter. The device name (ewa) for the DE500 indicates it is DEC Tulip based which is well supported on operating systems available for Alpha. The DEC Tulip ethernet adapters had a number of models and revisions of the ethernet adapters, some of which have behaviors that need additional configuration, so this information is useful to have.
HP Tru64
The UNIX on Alpha systems is an OSF/1 (Wikipedia) derivative. This was originally called DEC OSF/1 AXP, a name used through to the OSF/1 3.0 release in 1994. In 1995 there was a re-brand with the release of Digital UNIX 3.2. After the acquisition by Compaq in 1998, there was another re-brand with the 1999 release of Compaq Tru64 UNIX 4.0F. The Tru64 name stuck through Compaq's merger with HP, and was used through to the last release in 2010 of HP Tru64 UNIX 5.1B-6.
For looking at the emulated system I've installed HP Tru64 UNIX 5.1B. so let's see what Tru64 has to say about the emulated machine.
uname
System version and architecture information:
# uname -a OSF1 faxp-tru64 V5.1 2650 alpha
OSF1 is the system name for Tru64 and its predecessors, the release is V5.1, and the version 2650, which is the 'B' update, 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); Tue May 11 20:40:38 BST 2021 # sizer -c cpu "DEC2100_A50" # sizer -implver EV4
The OS version string confirms this is Tru64 5.1B.
Not sure what is going on with the CPU type. The AlphaServer 2100 line was originally marketed as the Digital 2100 AXP when it was introduced in 1994, before the change to AlphaStation and AlphaServer branding for the workstation and server lines. But the 2100 line is part of the "Sable" family of Alpha systems, and the AlphaServer 400 product line (Wikipedia) was part of the Avanti family. This might suggest a connection during development, but I haven't found any documentation confirming that.
The processor family is EV4 which is correct for the Alpha 21064 chip (the 21064A would be EV45), which is the expected chip for an AlphaServer 400 4/166.
psrinfo
Report processor information:
# psrinfo -v Status of processor 0 as of: 05/14/21 19:54:00 Processor has been on-line since 05/14/2021 19:21:53 The alpha EV4 (21064) processor operates at 1216 MHz, has a cache size of 262144 bytes, and has an alpha internal floating point processor.
We expect one Alpha EV4 and that is what we see. Although the AlphaServer 400 only featured a 166 MHz EV4 (the EV45 model ran at 233 MHz), the system claims we're getting >1 GHz. Great for performance if true...
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 DEC RZ40L bus-0-targ-0-lun-0
27: /dev/disk/cdrom0c DEC RRD42 bus-0-targ-6-lun-0
28: /dev/random
29: /dev/urandom
# hwmgr view hierarchy
HWID: hardware hierarchy
-------------------------------------------------------------------------------
1: platform AlphaServer 400 4/166
2: cpu CPU0
6: bus pci0
7: connection pci0slot6
13: scsi_adapter psiop0
14: scsi_bus scsi0
26: disk bus-0-targ-0-lun-0 dsk0
27: disk bus-0-targ-6-lun-0 cdrom0
9: connection pci0slot7
15: bus isa0
16: connection isa0slot0
17: keyboard keyboard0
18: pointer mouse0
19: connection isa0slot2
20: serial_port tty00
21: connection isa0slot3
22: serial_port tty01
23: connection isa0slot4
24: parallel_port lp0
11: connection pci0slot11
25: network tu0
So the system is identified as an AlphaServer 400 4/166, as expected, with one CPU, a SCSI hard disk and CD-ROM drives, the typical system ports and a Tulip based network card. All as expected for the emulated system.
Does seem a little odd that SRM reported a floppy controller, but there doesn't appear to be one here. Give that floppies are very seldom used with these systems, and when they are it's for firmware changes, this is a very minor issue.
vmstat
Virtual memory information with some additional physical memory information:
# vmstat -P
Total Physical Memory = 128.00 M
= 16384 pages
Physical Memory Clusters:
start_pfn end_pfn type size_pages / size_bytes
0 249 pal 249 / 1.95M
249 16383 os 16134 / 126.05M
16383 16384 pal 1 / 8.00k
Physical Memory Use:
start_pfn end_pfn type size_pages / size_bytes
249 289 scavenge 40 / 320.00k
289 1064 text 775 / 6.05M
1064 1207 data 143 / 1.12M
1207 1435 bss 228 / 1.78M
1435 1630 kdebug 195 / 1.52M
1630 1637 cfgmgmt 7 / 56.00k
1637 1639 locks 2 / 16.00k
1639 1653 pmap 14 / 112.00k
1653 1749 unixtable 96 / 768.00k
1749 1752 logs 3 / 24.00k
1752 2096 vmtables 344 / 2.69M
2096 16383 managed 14287 / 111.62M
============================
Total Physical Memory Use: 16134 / 126.05M
Managed Pages Break Down:
free pages = 2746
active pages = 4322
inactive pages = 0
wired pages = 2159
ubc pages = 5100
==================
Total = 14327
WIRED Pages Break Down:
vm wired pages = 491
ubc wired pages = 0
meta data pages = 441
malloc pages = 779
contig pages = 28
user ptepages = 400
kernel ptepages = 13
free ptepages = 7
==================
Total = 2159
So the memory system also sees the expected 128 MB from the emulator configuration.
Benchmarks
The psrinfo result that gives a clock speed >1 GHz is intriguing... So does this machine perform like a >1 GHz Alpha? Let's try some simple benchmarks and see what we get...
BogoMips
The "busy doing nothing" benchmark, BogoMips were derived from a the need to calibrate a busy-wait loop in the Linux kernel. Fortunately the BogoMips mini-Howto gives a set of results from real Alpha hardware running Linux (4.10. Alpha Systems) and other operating systems (4.17. Non-Linux systems (reference only)) for comparison. The BogoMips Wikipedia page features a table giving expected clock speed multipliers for deriving BogoMips readings (Proper BogoMips Ratings). Since we're not running Linux we'll use a portable implementation (bogo-1.2.tar.gz) of about the same era as most of the collected results.
As an additional check we'll compare against some figures collected on real Alpha hardware running multiple operating systems:
| System Name | CPU | MHz | OS | BogoMips | Notes |
|---|---|---|---|---|---|
| laurus | DEC Alpha 21164A (EV56) | 533 | HP Tru64 5.1b | 528.00 | bogomips 1.3 |
| laurus | DEC Alpha 21164A (EV56) | 533 | Linux 2.2 | 528.12 | /proc/cpuinfo |
| laurus | DEC Alpha 21164A (EV56) | 533 | NetBSD 1.5.2 | 531.55 | bogomips 1.3 |
| laurus | DEC Alpha 21164A (EV56) | 533 | Linux 2.4 | 1059.80 | /proc/cpuinfo |
| laurus | DEC Alpha 21164A (EV56) | 533 | Linux 2.6.11 | 1059.80 | /proc/cpuinfo |
| sarothamnus | Alpha 21264B (EV68AL) | 800 | Linux 2.6.11 | 1586.36 | /proc/cpuinfo |
N.B. The doubling of results between the Linux 2.2 and 2.4 kernels was due to some code changes, see "3.5. New BogoMips algorithm?" in the BogoMips mini-Howto and the README for the BogoMips 1.4 implementation for an explanation.
So using a simple script to run the the bogomips program, from the bogo-1.2 distribution, 5 times we get:
faxp-tru64> bogo.sh Calibrating delay loop.. ok - 150.00 BogoMips Calibrating delay loop.. ok - 150.00 BogoMips Calibrating delay loop.. ok - 150.00 BogoMips Calibrating delay loop.. ok - 150.00 BogoMips Calibrating delay loop.. ok - 150.00 BogoMips
Hmmm... that seems very low compared to the >1 GHz clock speed. But wouldn't be too far off if running on real AlphaStation 400 4/166 hardware, where the processor was clocked at 166 MHz, assuming the clock * 0.99 estimate works (166 * 0.99 = 165.34). The estimate is consistent with my own observations on real hardware, which suggests an effective clock speed of about 150 MHz.
However a look at the recorded BogoMips scores for non-Linux systems has scores for older Alpha systems running OSF1 (the old name for Tru64) that are consistently around half the clock speed. Since this emulated machine is aiming for a Alpha EV4, that would suggest an effective clock speed of 300 MHz.
In either case these indicate actual performance is lower than that >1 GHz clock frequency figure would suggest. Which is what we would expect for an emulation since the host is not that much more powerful than the guest (especially since FreeAXP runs single threaded).
OpenSSL
OpenSSL provides a means of assessing the performance of the provided cryptographic algorithms, and is installed as part of the standard packages for Tru64.
# openssl speed md5
Doing md5 for 3s on 8 size blocks: 165769 md5's in 2.98s
Doing md5 for 3s on 64 size blocks: 93653 md5's in 3.00s
Doing md5 for 3s on 256 size blocks: 40673 md5's in 3.00s
Doing md5 for 3s on 1024 size blocks: 12507 md5's in 3.00s
Doing md5 for 3s on 8192 size blocks: 1676 md5's in 3.00s
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 444.52k 1997.93k 3470.76k 4269.06k 4576.60k
# openssl speed rsa
Doing 512 bit private rsa's for 10s: 551 512 bit private RSA's in 10.00s
Doing 512 bit public rsa's for 10s: 7364 512 bit public RSA's in 9.98s
Doing 1024 bit private rsa's for 10s: 126 1024 bit private RSA's in 10.02s
Doing 1024 bit public rsa's for 10s: 2582 1024 bit public RSA's in 9.98s
Doing 2048 bit private rsa's for 10s: 22 2048 bit private RSA's in 10.33s
Doing 2048 bit public rsa's for 10s: 754 2048 bit public RSA's in 10.00s
Doing 4096 bit private rsa's for 10s: 4 4096 bit private RSA's in 12.07s
Doing 4096 bit public rsa's for 10s: 217 4096 bit public RSA's in 10.00s
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.0181s 0.0014s 55.1 737.6
rsa 1024 bits 0.0795s 0.0039s 12.6 258.6
rsa 2048 bits 0.4697s 0.0133s 2.1 75.4
rsa 4096 bits 3.0167s 0.0461s 0.3 21.7
Extracting relevant figures for comparisons:
- OpenSSL speed MD5 8,192 bytes: 4,576.60k
- OpenSSL speed RSA 4,096 bytes sign/s: 0.3
- OpenSSL speed RSA 4,096 bytes verify/s: 21.7
Now to collect more figures for comparison.
Thoughts
So FreeAXP looks to keep HP Tru64 very happy, and the emulated AlphaServer 400 4/166 hardware looks to match the actual hardware, except for differences in performance and having a few more restrictions on the available hardware.
FreeAXP is targeted at hobbyist customers and as an evaluation product for corporate use. So the limited range of hardware available makes sense, as does the lack of performance tuning options. Part of the performance limitation could be trying to replicate Alpha instruction timings, something that can be important in some applications. This would make a lot of sense of an evaluation product for a service targeted at providing system migration options for applications that cannot be simply moved to other platforms.
Further Sources
- Alpha SRM
- HP Tru64
- Tru64 5.1B Unix and Oracle 9i infosec exercise
- QuickSpecs. HP Tru64 UNIX Operating System Version 5.1B-6 Overview. Retired - PDF Free Download
- Linux for Alpha on QEMU
Update 16-Jun-2021: added OpenSSL benchmark.
No comments:
Post a Comment