TL;DR obvious profile differences in at least KERNEL mode begs some questions about x86-64 VMS. This item is more about X86 VMS and less about WASD but still uses WASD as a part of the measurement process. When running OWSP ZAP web app scanner against Alpha and x86-64 versions of OpenVMS during WASD testing, distinctly differing profiles of CPU modes were immediately evident. Perhaps not unexpected considering x86-64 VMS basically emulates a 4 mode (KESU) access to memory using some sleight of hand not required with any previous CPU architecture (VAX, Alpha, Itanium) and so is more expensive (at least that is my lay understanding). The far more obvious presence of KERNEL in these simple tests do beg some questions. Please consider this post only as food for thought. The original observations were made during the earlier reported reliability testing and then again with WASD/Apache metrics https://wasd.vsm.com.au/info-WASD/2023/0054 OWASP ZAP ZAP will proceed to crawl the web application with its spider and passively scan each page it finds. Then ZAP will use the active scanner to attack all of the discovered pages, functionality, and parameters. https://www.zaproxy.org/getting-started/ ZAP is the preferred WASD site exercise and testing tool these days, and before new versions are released, literally hundreds of thousands of 10, 20, 30 concurrent ZAP requests, are run against WASD establishing some confidence that obvious issues are winnowed out. Of course this does not guarantee bug-free releases :-) but does improve the chances. https://wasd.vsm.com.au/wasd_root/wasdoc/config/#serverandsitetesting ZAP is also used for this KERNEL mode exercise because it results in a "crawl" of similar portions of underlying files and executables (scripts) across multiple independent systems and so represents similar profiles of NETWORK, SYSTEM SERVICE, APPLICATION ACTIVATION AND OTHER ASPECTS of system behaviour. The reference "real hardware" system was a "Digital Personal WorkStation with 1 CPU and 1536MB running VMS V8.4-2L1", rated at approximately 152 VUPs. "HP TCP/IP Services for OpenVMS Alpha Version V5.7 - ECO 5" The reference "hypervised hardware" system an "innotek GmbH VirtualBox with 2 CPU and 7574MB running VMS V9.2", rated at approximately 272 VUPs. "VSI TCP/IP Services for OpenVMS x86_64 Version X6.0" To ensure as much equity as possible the x86-64 had a second CPU disabled, making both systems essentially single CPU. |X86VMS$ show cpu | |System: X86VMS, innotek GmbH VirtualBox | |CPU ownership sets: | Active 0 | Configure 0,1 Data collected using MONITOR MODES /AVERAGE and after approximately 50k requests being processed. | OpenVMS Monitor Utility | +-----+ TIME IN PROCESSOR MODES | | AVE | on node X86VMS | +-----+ 24-APR-2023 13:02:51.05 | | 0 25 50 75 100 | + - - - - + - - - - + - - - - + - - - - + | Interrupt State 6 |** | MP Synchronization | | Kernel Mode 69 |*************************** | Executive Mode 5 |** | Supervisor Mode | | User Mode 17 |****** | Compatibility Mode | | Idle Time 3 |* | + - - - - + - - - - + - - - - + - - - - + Now, we all know that V9.2 is an early, unoptimised release, but it needs to be asked exactly why the very prominent value for KERNEL mode at the expense of USER mode, compared to the Alpha below. X86 KERNEL using in excess of TWO THIRDS the available CPU. | OpenVMS Monitor Utility | +-----+ TIME IN PROCESSOR MODES | | AVE | on node KLAATU | +-----+ 24-APR-2023 15:15:57.53 | | 0 25 50 75 100 | + - - - - + - - - - + - - - - + - - - - + | Interrupt State 8 |*** | MP Synchronization | | Kernel Mode 22 |******** | Executive Mode 8 |*** | Supervisor Mode 1 | | User Mode 47 |****************** | Compatibility Mode | | Idle Time 14 |***** | + - - - - + - - - - + - - - - + - - - - + One would expect a lot more "real" work being accomplished in USER mode. The MONITOR SYSTEM /AVERAGE doesn't reveal any huge disparities between the two architectures, except the greater CPU consumed by the X86 VM, possibly only reflecting the increased kernel mode used. |Node: X86VMS OpenVMS Monitor Utility 24-APR-2023 13:04:19 |Statistic: AVERAGE SYSTEM STATISTICS | Process States | + CPU Busy (96) -+ LEF: 18 LEFO: 0 | |************************ | HIB: 16 HIBO: 0 |CPU 0 +--------------------------+ 100 COM: 5 COMO: 0 | |***** | PFW: 0 CUR: 1 | +--------------------------+ MWAIT: 2 Other: 0 | Cur Top: WASD:80_05E8 (22) Total: 42 | | + Page Fault Rate (152) -+ + Free List Size (599239) + | |*|***** | |**************** | 947K |MEMORY 0 +--------------------------+ 500 0 +--------------------------+ | |* | | | 95K | +--------------------------+ + Mod List Size (1091) + | Cur Top: WASD:80_05E0 (27) | | + Direct I/O Rate (133) -+ + Buffered I/O Rate (349) -+ | |****** | |****************** | |I/O 0 +--------------------------+ 500 0 +--------------------------+ 500 | | | |***** | | +--------------------------+ +--------------------------+ | Cur Top: WASD:80_05E2 (6) Cur Top: WASD:80 (97) |Node: KLAATU OpenVMS Monitor Utility 24-APR-2023 15:16:47 |Statistic: AVERAGE SYSTEM STATISTICS | Process States | + CPU Busy (87) -+ LEF: 26 LEFO: 0 | |********************** | HIB: 17 HIBO: 0 |CPU 0 +--------------------------+ 100 COM: 3 COMO: 0 | | | PFW: 0 CUR: 1 | +--------------------------+ MWAIT: 0 Other: 0 | Cur Top: TCPIP$INETACP (0) Total: 47 | | + Page Fault Rate (329) -+ + Free List Size (69207) + | |**|************** | |********* | 192K |MEMORY 0 +--------------------------+ 500 0 +--------------------------+ | | | |**** | 19K | +--------------------------+ + Mod List Size (3741) + | Cur Top: (0) | | + Direct I/O Rate (219) -+ + Buffered I/O Rate (671) -+ | |*********** | |**************************| |I/O 0 +--------------------------+ 500 0 +--------------------------+ 500 | | | | | | +--------------------------+ +--------------------------+ | Cur Top: TCPIP$INETACP (5) Cur Top: TCPIP$INETACP (10) Something to keep our eyes on as X86 VMS develops over time. This item is one of a collection at https://wasd.vsm.com.au/other/#occasional