VSI FreeAXP Student kit and MONITOR display problem

As first reported in comp.os.vms

groups.google.com/g/comp.os.vms/c/0FGKGIX83Js

there is a problem with displaying MONITOR data in OpenVMS Alpha V8.4-2L2 when running in FreeAXP 4.0.0.646 as delivered with the VSI Student Kit 2020.2. After reading the problem description, I decided to try to quickly reproduce this problem by downloading and installating the 2020.2 student kit and yes, this problem is reproducable !

Avanti Virtual Alpha version 4.0.0.646 (Apr 14 2020 14:36:57)

$ sho sys/noproc
OpenVMS V8.4-2L2 on node STUDNT 6-MAR-2021 09:51:41.17 Uptime 0 00:07:03
$

Directory SYS$COMMON:[SYSEXE]

MONITOR.EXE;1 22-MAY-2017 22:50:19.68

Image Identification Information

image name: "MONITOR"
image file identification: "X-27"
image file build identification: "XE6K-0100140000"
link date/time: 22-MAY-2017 22:50:19.45
linker identification: "A13-04"




OpenVMS Monitor Utility
SYSTEM STATISTICS
on node STUDNT
6-MAR-2021 09:47:25.05

CUR AVE MIN MAX

Interrupt State 0.49 0.39 0.16 0.66
MP Synchronization 0.00 0.00 0.00 0.00
Kernel Mode 0.16 0.06 0.00 0.16
Executive Mode 0.00 0.00 0.00 0.00
Supervisor Mode 0.00 0.00 0.00 0.00
User Mode 0.33 0.19 0.00 0.33
Compatibility Mode 0.00 0.00 0.00 0.00
Idle Time *******.** 99.34 *******.** *******.**
Process Count 10.00 10.00 10.00 10.00
Page Fault Rate 0.00 0.29 0.00 0.83
Page Read I/O Rate 0.00 0.03 0.00 0.16
Free List Size 9555.00 9555.60 9555.00 9558.00
Modified List Size 447.00 447.19 447.00 448.00
Direct I/O Rate 0.00 0.03 0.00 0.16
Buffered I/O Rate 0.49 0.53 0.33 0.83

OpenVMS Monitor Utility
DISK I/O STATISTICS
on node STUDNT
6-MAR-2021 09:49:53.72

I/O Operation Rate CUR AVE MIN MAX

STUDNT$DKA0: STUDSYS *****.** 100.65 *******.** *******.**

As reported in comp.os.vms, this problem does NOT occur, if running the same virtual disk in CHARON-AXP or on a real ES47.

I can make the associated FreeAXP Log file (OpenVMS Studentpackacke.log) available, if required.

Volker.

I've reproduced the problem using FreeAXP 653 and OpenVMS 8.4-2L2.

The problem does not occur under VMS 8.3 or 8.4.

We'll have a look at the issue. Thanks for the bug report.<hr>

Bruce,

did you try MONITOR/RECORD SYSTEM/ALL under V8.4 and then just display that MONITOR.DAT file on V8.4-2L2 using MONITOR/INPUT=MONITOR.DAT SYSTEM/ALL - still the asterisks for Idle Time ? This would rule out any MONITOR data-collection problems.

Note that MONITOR has been changed in V8.4-2L1:

3.1.12 MONITOR Utility: MONITOR IO FREE LIST SIZE field overflow on large memory systems

V8.4-2L2 MONITOR SYSTEM/ALL has been reported to work o.k. on a real ES47, but the above 'fix' was apparently to the same MONITOR class display, so it may be related.

Idle Time of *******.** for CUR, MIN and MAX is completely bogus, AVG 99.34 - in my case - looks good.

Volker.

Bruce,

further testing results: running MONITOR ALL/ALL shows the asterisks problem on different displays (IO,PAGE,DISK,TIMER), but it depends on load, i.e. whether the default values of 0.00 get overwritten by the measurement data. The asterisks may show up as '0.**' or '*******.**'
MONITOR TIMER is really showing lots of asterisks, as most of the data measured/shown are nearly always non-zero.

Now a little bit of speculation about the possible underlying problem:

- OpenVMS Alpha V8.4-2L2 has been completely rebuilt/recompiled for EV6 support
- the problem does not show up on a real ES47 and a CHARON-AXP/DS20, both EV6 machines
- FreeAXP is emulating an AlphaServer 400, an EV4 CPU - 'enhanced' for EV6 support
- now if the newly built OpenVMS Alpha V8.4-2L2 and the new MONITOR include some
instructions beyond EV4, there is some risk of seeing a possible 'bug' in instruction emulation

Volker.

Thanks Volker!

Some troubleshooting results using MONITOR/RECORD TIMER:

When displaying the data, MONITOR uses the absolute counter values PMS$GQ_TQE* from the system (or from the MONITOR.DAT file), builds the differences from the values collected/recorded in the previous interval, then converts the differences to floating-point values and ides it through the collection interval length, building rate/second floating values.

These floating values are then converted to the whole part and the fractional part and stored as integers. These integer values are then output using $FAOL_S and control strings containing multiple "!7UL.!2UL"

So 'the problem' seems to be somewhere in those conversion code pathes (see MONITOR.LIS routine COMPUTE_STATS).

You would probably need the current MONITOR source listing to have a chance to further debug this. A MONITOR.EXE built with /DEBUG would certainly help here...

Volker.