ibm - virtual machine/ enterprise systems architecture performance report version … ·...

Virtual Machine/Enterprise Systems Architecture

Performance ReportVersion 2 Release 3

March 19, 1998

VM Performance Group

IBM CorporationEndicott, New York

[email protected]

Copyright International Business Machines Corporation 1998. All rights reserved.Note to U.S. Government Users — Documentation related to restricted rights — Use, duplication or disclosure issubject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.

Contents

Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vProgramming Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vTrademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viAcknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi

Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

Referenced Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii i

Summary of Key Findings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Changes That Affect Performance . . . . . . . . . . . . . . . . . . . . . . . . . . 3Performance Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Performance Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Performance Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Measurement Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Format Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Tools Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Migration from VM/ESA 2.2.0 and TCP/IP 2.4 . . . . . . . . . . . . . . . . . . . . 13CMS-Intensive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

9121-742 / Minidisk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139121-480 / Minidisk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179121-480 / SFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

VSE/ESA Guest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Migration from Other VM Releases . . . . . . . . . . . . . . . . . . . . . . . . . . 39

New Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Record Level Minidisk Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44fork() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48MQSeries Client Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Additional Evaluations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Migration from VTAM to Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51Reduced TCP/IP Real Storage Requirements . . . . . . . . . . . . . . . . . . . . 58Improved SMTP Server Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . 62OfficeVision 1.4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67OfficeVision SFS A-Directory Support . . . . . . . . . . . . . . . . . . . . . . . . 71

Appendix A. Workloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78CMS-Intensive (FS8F) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78IBM Office Benchmark (IOB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88VSE Guest (DYNAPACE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Copyright IBM Corp. 1998 iii

Appendix B. Configuration Details . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Glossary of Performance Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

iv VM/ESA V2R3.0 Performance Report

Notices

The information contained in this document has not been submitted to anyformal IBM test and is distributed on an as is basis without any warranty eitherexpressed or implied . The use of this information or the implementation of anyof these techniques is a customer responsibility and depends on the customer ′sability to evaluate and integrate them into the customer′s operationalenvironment. While each item may have been reviewed by IBM for accuracy ina specific situation, there is no guarantee that the same or similar results will beobtained elsewhere. Customers attempting to adapt these techniques to theirown environments do so at their own risk.

Performance data contained in this document were determined in variouscontrolled laboratory environments and are for reference purposes only.Customers should not adapt these performance numbers to their ownenvironments as system performance standards. The results that may beobtained in other operating environments may vary significantly. Users of thisdocument should verify the applicable data for their specific environment.

This publication refers to some specific APAR numbers that have an effect onperformance. The APAR numbers included in this report may haveprerequisites, corequisites, or fixes in error (PEs). The information included inthis report is not a replacement for normal service research.

References in this publication to IBM products, programs, or services do notimply that IBM intends to make these available in all countries in which IBMoperates. Any reference to an IBM licensed program in this publication is notintended to state or imply that only IBM′s program may be used. Anyfunctionally equivalent product, program, or service that does not infringe any ofthe intellectual property rights of IBM may be used instead of the IBM product,program, or service. The evaluation and verification of operation in conjunctionwith other products, except those expressly designated by IBM, are theresponsibility of the user.

IBM may have patents or pending patent applications covering subject matter inthis document. The furnishing of this document does not give you license tothese patents. You can send inquiries, in writing, to the IBM Director ofLicensing, IBM Corporation, 208 Harbor Drive, Stamford, CT, 06904-2501 USA.

Programming InformationThis publication is intended to help the customer understand the performance ofVM/ESA 2.3.0 on various IBM processors. The information in this publication isnot intended as the specification of any programming interfaces that areprovided by VM/ESA 2.3.0. See the IBM Programming Announcement forVM/ESA 2.3.0 for more information about what publications are considered to beproduct documentation.

Copyright IBM Corp. 1998 v

TrademarksThe following terms, denoted by an asterisk (*) in this publication, aretrademarks of the IBM Corporation in the United States or other countries orboth:

AIXACF/VTAMCICSDisplayWriteES/9000IBMMQMQSeriesMVSOfficeVisionOpenEditionOS/2PR/SMProcessor Resource/Systems ManagerRAMACRS/6000System/390S/390Virtual Machine/Enterprise Systems ArchitectureVM/ESAVM/XAVSE/ESAVTAM3090

Acknowledgements

The following people contributed to this report:

Bill BitnerWes ErnsbergerBill Guzior

vi VM/ESA V2R3.0 Performance Report

Abstract

The VM/ESA Version 2 Release 3.0 Performance Report summarizes theperformance evaluation of VM/ESA 2.3.0, including TCP/IP Function Level 310.Measurements were obtained for CMS-intensive, VSE guest, Telnet, and FTPenvironments on various ES/9000 processors. Discussion covers theperformance changes in VM/ESA 2.3.0, the performance effects of migrating fromVM/ESA 2.2.0 to VM/ESA 2.3.0, the performance effects of migrating from TCP/IP2.4 to TCP/IP 310, the performance of new functions provided in VM/ESA 2.3.0,and additional evaluations.

Copyright IBM Corp. 1998 vii

Referenced Publications

The following publications and documents are referred to in this report.

• VM/ESA: Performance, SC24-5782

• VM/ESA: CMS File Pool Planning, Administration, and Operation, SC24-5751

• C for VM/ESA Library Reference, SC23-3908

• CMS Application Development Guide, SC24-5450

• MQSeries: Application Programming Guide SC33-0807

The following publications are performance reports for earlier VM/ESA releases.The topics covered in these reports and this report are listed in the VM/ESAPerformance Report Directory at http://www.vm.ibm.com/perf/perfdir.html.

• VM/ESA Release 1.0 Performance Report, ZZ05-04691

• VM/ESA Release 1.1 Performance Report, GG66-3236

• VM/ESA Release 2 Performance Report, GG66-3245

• VM/ESA Release 2.1 Performance Report, GC24-5673-00

• VM/ESA Release 2.2 Performance Report, GC24-5673-01

• VM/ESA Version 2 Release 1.0 Performance Report, GC24-5801

• VM/ESA Version 2 Release 2.0 Performance Report,http://www.vm.ibm.com/perf/docs/

Much additional VM/ESA performance information is available on the VM/ESAperformance page at http://www.vm.ibm.com/perf/.

1 This report is no longer orderable. LIST38PP softcopy is available as VM10PERF PACKAGE on VMTOOLS. Or send a note [email protected] requesting a copy.

viii Copyright IBM Corp. 1998

Summary of Key Findings


This report summarizes the performance evaluation of VM/ESA* Version 2Release 3.0, including TCP/IP Function Level 310. Measurements were obtainedfor the CMS-intensive, VSE guest, Telnet, and FTP environments on variousES/9000* processors. This section summarizes the key findings. For furtherinformation on any given topic, refer to the page indicated in parentheses.

Performance Changes: VM/ESA 2.3.0 includes a number of performanceenhancements (page 3). Some changes have the potential to adversely affectperformance (page 6). Lastly, a number of changes were made that affectVM/ESA performance management (page 7).

Migration from VM/ESA 2.2.0 and TCP/IP 2.4

Benchmark measurements show the following performance results for VM/ESA2.3.0 relative to VM/ESA 2.2.0:

CMS-intensive Overall performance was similar to VM/ESA 2.2.0. The internalthroughput rate (ITR) decreased by an average 0.5% whileresponse time improved by an average of 1% (page 13).

VSE guest ITR decreased by an average 0.9% for the measured V=R andV=V environments, while elapsed times were equivalent (page29).

For the measured Telnet and FTP environments, TCP/IP 310 processor usage inthe TCPIP virtual machine decreased by 3.7% relative to TCP/IP 2.4. Thisimprovement resulted from the pathlength improvements made to the TCP/IPstack in this release (page 33).

Migration from Other VM Releases: The performance measurement data in thisreport can be used in conjunction with similar data in the previous VM/ESAperformance reports to get a general understanding of the performance aspectsof migrating from earlier VM releases to VM/ESA 2.3.0 (page 39).

New Functions

Minidisk caching now has a record level option for use in unusual cases wherethe default full track minidisk caching is not appropriate. Results illustrate thatrecord level caching is most suitable for applications that randomly access smallamounts of data in very large files (page 44).

Fork support: Processor usage measurements are provided for the fork(),execl(), and wait() OpenEdition functions (page 48).

MQSeries* client support: On a 2003-156, application virtual machine processorusage per MQGET or MQPUT was measured to be about 1 millisecond for a Capplication and about 14 milliseconds for a REXX application (page 49).

Additional Evaluations

Measurement results show similar response times and increased processorusage (8% to 12%) when migrating a CMS-intensive workload from VTAM toTCP/IP Telnet (page 51).

Copyright IBM Corp. 1998 1


Measurement results demonstrate that Telnet performance is no longeradversely affected by the presence of unused TCP/IP buffers. This results fromimprovements that were made in this area (page 58).

The maximum throughput that can be handled by any given SMTP server virtualmachine has been substantially increased with TCP/IP 310. For the measuredworkload and system configuration, throughput increase multiples ranging from1.6 to 3.4 relative to TCP/IP 2.4 were observed (page 62).

Overall performance of OfficeVision 1.4.0 decreased slightly relative toOfficeVision 1.3.0. External response time increased by 5%, while internalthroughput decreased by 1.1%. These differences should be appreciably smallerwhen running with the compiled version of the REXX execs supplied withOfficeVision (page 67).

OfficeVision 1.4.0 supports the use of an SFS directory as filemode A. IOBmeasurement results are provided for the case where an SFS directory is usedinstead of a minidisk for filemode A. In addition, a method is provided forestimating the percentage increase in processor usage for moving a givenamount of minidisk activity to SFS filecontrol directories (page 71).

2 VM/ESA V2R3.0 Performance Report

Performance Improvements

Changes That Affect Performance

This chapter contains descriptions of various changes to VM/ESA 2.3.0 that affectperformance. This information is also available at http://www.vm.ibm.com/perf,along with corresponding information for previous releases.

Most of the changes are performance improvements and are listed under“Performance Improvements.” However, some have the potential to adverselyaffect performance. These are listed under “Performance Considerations” onpage 6. The objectives of these two sections are as follows:

• Provide a comprehensive list of the significant performance changes.

• Allow installations to assess how their workloads may be affected by thesechanges.

Throughout the rest of the report, various references are made to these changeswhen discussing the measurement results. Those results serve to furtherillustrate where these changes apply and how they may affect performance.

“Performance Management” on page 7 is the third section of this chapter. Itdiscusses changes that affect VM/ESA performance management.

Performance ImprovementsThe following items improve the performance of VM/ESA.

• CP

− Reduced Segment Table Storage− Record Level Minidisk Cache− Improved Pacing for Secondary User Console Output

• CMS

− Execute Macro Rewrite− CMSINST Shared Segment Additions− PEEK Improvements

• TCP/IP

− Reduced TCP/IP Processor Usage− Reduced TCP/IP Real Storage Usage− TCP/IP RFC 1323− Increased SMTP Capacity

Reduced Segment Table StorageFor each virtual address space, CP must maintain a contiguous, page-alignedsegment table in fixed storage for the hardware to use to translate virtualaddresses into real addresses. In prior releases, the storage allocated for anygiven primary address space segment table was always one of three possiblesizes. Segment tables of 32M or less were allocated from space reserved at thebeginning of that virtual machine′s VMDBK and therefore took no additionalstorage. Primary address spaces greater than 32MB but not exceeding 1GB hadtheir segment table allocated from the beginning of a separate 4K page. Finally,primary address spaces greater than 1GB and up to the architechted maximumof 2GB had their segment table allocated from the beginning of two contiguous



4K pages. In either of these last two cases, any remaining space not needed forthe segment table was unused.

In VM/ESA 2.3.0, this space is now available for satisfying other user freestorage requests. As a result, fixed storage requirements go up in a much morecontinuous manner as segment table size increases. Although it is still best forperformance if the segment tables are small, it is no longer important to try tokeep the virtual machine segment table size below 32MB or, failing that, below1GB. The net effect of this change is to simplify shared segment and virtualmachine size management, and to improve performance in cases where largenumbers of segments or virtual machines exceed 32MB or 1GB.

Installations that currently define their shared segments top-down starting at1GB should consider relocating them to lower virtual address ranges in order tobenefit from this change.

Record Level Minidisk CacheThis support, first available on VM/ESA 2.1.0 and VM/ESA 2.2.0 as APARVM61045, has now been integrated into VM/ESA 2.3.0. It is intended for unusualcases where the default full track minidisk caching is not appropriate. Thistypically occurs when a large database (hundreds of cylinders) is implementedas a single CMS file and the application does large numbers of randomaccesses to small amounts of data in that file. With full track minidisk caching,this can result in serious cache thrashing in the DASD control unit, expandedstorage, and main storage. In such cases, using record level minidisk cache forthat file′s minidisk is likely to improve performance.

This support is limited to:

• 4KB-formatted CMS minidisks on non-FBA DASD

• I/O done by diagnose X′18′, diagnose X′A4′, diagnose X′250′, or the*BLOCKIO CP system service

Record level caching can be enabled by use of the RECORDMDC option with theSET MDCACHE MDISK command or the MINIOPT directory control statement.The current setting can be determined by using the QUERY MDCACHE MDISKcommand.

See “Record Level Minidisk Caching” on page 44 for measurement results. Seethe VM/ESA: Performance book for minidisk cache tuning guidelines.

Improved Pacing for Secondary User Console OutputThe pacing algorithm for console output directed to a secondary user(established using the CP SET SECUSER command) has been improved. In priorreleases, the pacing algorithm limited output to 22 lines per second. Once thislimit was reached, the virtual machine generating the output would besuspended for a second. If this virtual machine is a server doing tracing orotherwise generating a high rate of console I/O, that server ′s performance couldbe degraded. In VM/ESA 2.3.0, this problem has been reduced because the limithas been raised to 255 lines per second.



Execute Macro RewriteThe EXECUTE Xedit macro was rewritten for improved performance andmaintainability. This resulted in a 6% CPU usage reduction for EXECUTE whenused by FILELIST and a 13% CPU usage reduction for EXECUTE when used byRDRLIST. EXECUTE macro CPU usage is essentially unchanged when used byDIRLIST, CSLLIST, or MACLIST.

CMSINST Shared Segment AdditionsThe following additional CMS system files have been moved into CMSINST:

ALL XEDIT (ALL Xedit command) APILOAD EXEC (add REXX copy files for multitasking)

DEFAULTS EXEC (setup for productivity aids)EXECUPDT EXEC (apply updates to an executable)HELP XEDIT (HELP in Xedit)JOIN XEDIT (JOIN in Xedit)MOREHELP EXEC (HELP for more information)OPENVM EXEC (front end to OPENVM)

PREFIXX XEDIT (X prefix command)PRFSHIFT XEDIT (> prefix command)

PRFSHOW XEDIT (S prefix command)PROFTMPL XEDIT (profile for templates)

RECEIVE XEDIT (RECEIVE from PEEK) RGTLEFT XEDIT (PF10 in default Xedit)

SPLTJOIN XEDIT (PF11 in default Xedit)X$EUPD$X XEDIT (EXECUPDT with NOCOMMENT option)X$EXCM$X EXEC (EXECMAP)X$LKED$X XEDIT (LKED)X$TMPL$X XEDIT (TEMPLATE option with CSLLIST)

When these functions are used, this change decreases per-user real storagerequirements and eliminates the processor time and I/Os that were required toload them from the S-disk into memory.

PEEK ImprovementsA number of changes were made to the PEEK command for improved functionand performance. The performance results depend upon the format of the filebeing viewed. Measurements showed a 17% CPU usage reduction for print files,a 15% reduction for punch files, and a 25% reduction for disk dump files. Therewas no significant change in the performance of PEEK for NETDATA files.

Reduced TCP/IP Processor UsageProcessor usage by the TCPIP virtual machine has been reduced by 3.7% for themeasured environments. An additional processor usage improvement (up to1%) can be realized on processors that support the checksum (CKSM)instruction.

See “TCP/IP” on page 33 for measurement results.

Reduced TCP/IP Real Storage UsageIn prior TCP/IP releases, an increase in the TCP/IP buffer pool sizes resulted inan increase in TCPIP virtual machine real storage usage, even when theadditional buffers were never used. With TCP/IP 310, this has been corrected sothat excess buffers have no appreciable effect on TCPIP real storagerequirements. This means that you can now provide extra buffers without therisk of undesirable performance effects.

Changes That Affect Performance 5

Performance Considerations

See “Reduced TCP/IP Real Storage Requirements” on page 58 for measurementresults.

TCP/IP RFC 1323TCP/IP 310 implements RFC 1323, a TCP protocol extension that allows windowsizes exceeding 64KB to be negotiated. This RFC applies to high bandwidth,high latency connections. In such cases, it can increase maximum throughputby increasing the amount of data that can be transmitted before anacknowledgement from the receiving system is required.

Increased SMTP CapacityThe SMTP server has been redesigned so that it does fewer minidisk I/Os andreads spool files asynchronously (using the *SPL CP system service). Thesechanges have resulted in substantial improvements to the maximum throughputthat one SMTP server virtual machine can deliver. Example measurementsshow 1.3-fold to 3.4-fold throughput increases relative to TCP/IP 2.4. The actualdegree of improvement that will be experienced on a given system configurationwill primarily depend upon where the SMTP log file is written (spool or minidisk),average access time to the DASD volume containing the SMTP A-disk, theaverage access time to the spool volumes, processor availability, and processorspeed. The largest relative improvements will be observed on systems wherethe log file is written to spool and that are characterized by long DASD accesstimes, high processor availability, and high processor speed.

See “Improved SMTP Server Capacity” on page 62 for measurement results.

Performance ConsiderationsThese items warrant consideration since they have potential for a negativeimpact to performance.

• DASD I/O Queue Ordering Algorithm Removed• Potential Shared Segment Overlaps• NFS Performance

DASD I/O Queue Ordering Algorithm RemovedIn prior releases, CP ordered DASD I/O requests in an attempt to minimize seektime. This has been made obsolete and, in some cases, even counterproductiveby the newer DASD technologies. In addition, in certain unusual cases, thisalgorithm can result in very long service delays for a given user. Because ofthese considerations, this algorithm has been disabled.

For the great majority of cases, this change is expected to have either nodiscernible effects or result in improved system characteristics. However, DASDI/O access times might increase in some situations. This is more likely onsystems with substantial DASD I/O queueing, old DASD, and non-cached controlunits.

Potential Shared Segment OverlapsThe portion of the CMS saved system that resides above the 16MB line has beenextended by one megabyte and now ends at location X′13FFFFF′. Whileinstalling VM/ESA 2.3.0, check to make sure that this has not caused anyoverlaps with other shared segments in your system. In addition, if you haveany non-relocatable modules that were generated to load between X′1300000′and X′13FFFFF′, they will need to be regenerated to run in another location.


Performance Management

NFS PerformanceThe performance of NFS when used with shared file system or byte file systemdirectories is significantly less than the performance of NFS when used withCMS minidisks.

Performance ManagementThese changes affect the performance management of VM/ESA and TCP/IP VM.

• Monitor Enhancements• Improved MONVIEW Performance• NETSTAT Enhancements• Effects on Accounting Data• VM Performance Products

Monitor EnhancementsA number of new monitor records and fields have been added. Some of themore significant changes are summarized below. For a complete list ofchanges, see the MONITOR LIST1403 file (on MAINT′s 194 disk) for VM/ESA 2.3.0.

• System Configuration Data

Various fields were added to the system configuration data record (domain 1record 4). These include the volume serial numbers for the checkpoint andwarm start areas and the system identifier name.

• IUCV Connection Information

Two new fields were added to the user activity data record (domain 4 record3). These fields are the maximum number of IUCV connections allowed andthe current number of IUCV connections in use. The maximum number ofconnections is from the system default or the MAXCONN setting in the userdirectory entry.

• Improved MDC Counter

The MDC read request count in the expanded storage data record (domain 0record 14) is now more accurate. In previous releases, it was possible forthis number to be inaccurate in either direction. This field is often used tocompute MDC hit ratios.

• APPLDATA (domain 10) Interface

Enhancements were made to diagnose X′DC′, which is the interfaceapplications can use to contribute data to the monitor. Applications can noweasily contribute event and configuration data to the APPLDATA domain.

APPLDATA monitor records are now being contributed by two TCP/IPservers—TCPIP and TFTPD—to allow for improved monitoring of theirperformance.

• TCPIP

The TCP/IP 310 stack machine can now generate APPLDATA event andsample records. The layouts of these records are provided in thePerformance manual. The following types of records are produced:



TYPE Rec Description

Sample 00 TCP/IP MIB RecordEvent 01 TCP/IP TCB Open RecordEvent 02 TCP/IP TCB Close Record

Config 03 TCP/IP Pool Limit Record Sample 04 TCP/IP Pool Size Record Sample 05 TCP/IP LCB Record

Event 06 TCP/IP UCB Open RecordEvent 07 TCP/IP UCB Close Record

Config 08 TCP/IP Link Definition Record Sample 09 TCP/IP ACB Record Sample 0A TCP/IP CPU Record

Event 0B TCP/IP CCB Record Sample 0C TCP/IP Tree Size Record Config 0D TCP/IP Home Record

These records are provided if the APPLMON option is specified for the TCPIPvirtual machine, subject to the new MONITORRECORDS statement in thePROFILE TCPIP configuration file:

NORECORDS no monitor records (default)MOSTRECORDS all records except for the ACB recordsALLRECORDS all monitor records

• TFTPD

The TFTPD server was first introduced as an APAR to TCP/IP 2.4 as part ofVM/ESA′s support for the IBM Network Station. TFTPD contributesAPPLDATA sample records to CP monitor. These records are alwaysprovided if the APPLMON option is specified for the TFTPD virtual machine.They can be used to get a more detailed understanding of the work that isbeing performed by the TFTPD server. The information provided includes:

files read by clientbytes readfiles read from cacheelapsed time spent reading filesfiles written to the TFTPD serverbytes writtenelapsed time spent writing filesinformation on failed transactionstimeouts waiting for an acknowledgement

Improved MONVIEW PerformanceThe MDATPEEK stage, which is part of the MONVIEW tool that is shipped on the3B2 samples disk was rewritten from REXX to assembler. This greatly improvesMONVIEW performance for certain cases. MONVIEW can be used to view CPmonitor data. For more information on MONVIEW, see the MONVIEW SAMPLISTfile on the samples disk.

NETSTAT EnhancementsNETSTAT has been improved to have greater selectability, limiting the amount ofoutput to what you actually need. In addition, the NETSTAT INTERVAL commandnow has a fullscreen interface where the data can be scrolled and sorted byfield.



Effects on Accounting DataNone of the VM/ESA 2.3.0 performance changes are expected to have asignificant effect on the values reported in the virtual machine resource usageaccounting record.

VM Performance ProductsThis section contains information on the support for VM/ESA 2.3.0 provided byVMPRF, RTM/ESA, FCON/ESA, and VMPAF.

VM Performance Reporting Facility 1.2.1 (VMPRF) will run on VM/ESA 2.3.0 withthe same support as VM/ESA 2.2.0. The latest service is recommended.

Realtime Monitor VM/ESA 1.5.2 (RTM/ESA) requires APAR GC05430 (PTFUG03868) to run on VM/ESA 2.3.0. RTM/ESA has been updated to use a fieldnew to VM/ESA 2.3.0 when calculating the minidisk hit ratio. With this new field,the calculation corresponds more closely to the value returned from the CPINDICATE command. RTM/ESA will continue to do the old calculation whenrunning on earlier VM/ESA releases.

FCON/ESA Versions 2.3.02 and 3.1.00 will run on VM/ESA 2.3.0 with the samesupport as VM/ESA 2.2.0.

Performance Analysis Facility/VM 1.1.3 (VMPAF) will run on VM/ESA 2.3.0 withthe same support as VM/ESA 2.2.0.


Measurement Information


This chapter discusses the types of processors used for measurements in thereport, the levels of software used, the configuration details associated with eachmeasurement, and the licensed programs and tools that were used in runningand evaluating the performance measurements.

HardwareThe following processors were measured.

• 9121-742

• 9121-480

• 9121-320

To run as a 9121-320, one processor was varied offline from the 9121-480hardware configuration screen.

SoftwareA pre-GA (General Availability) level of VM/ESA 2.3.0 was used for themeasurements in this report.

Other VM/ESA releases were measured for this report. VM/ESA 2.2.0 was at theGA+first-RSU (Recommended Service Upgrade) level. The service that waspart of VM/ESA 2.2.0 after the first RSU level and integrated into VM/ESA 2.3.0can account for some of the performance differences between VM/ESA 2.2.0 andVM/ESA 2.3.0.

See the appropriate workload section in Appendix A, “Workloads” on page 78for the other licensed programs′ software levels.

Format DescriptionThis part of the report contains a general explanation of the configuration detailsthat are associated with each measurement.

For each group of measurements there are five sections:

1. Workload: This specifies the name of the workload associated with themeasurement. For more detail on the workload, see Appendix A,“Workloads” on page 78.

2. Hardware Configuration: This summarizes the hardware configuration andcontains the following descriptions:

• Processor model: The model of the processor.

• Processors used: The number of processor engines used.

• Storage: The amount of real and expanded storage used on theprocessor.

− Real: The amount of real storage used on the processor.

− Expanded: The amount of expanded storage used on the processor.

• Tape: The type of tape drive and the tape′s purpose.

• DASD: The DASD configuration used during the measurement.

10 Copyright IBM Corp. 1998


The table indicates the type of DASD used during the measurement, typeof control units that connect these volumes to the system, the number ofpaths between the processor and the DASD, and the distribution of theDASD volumes for PAGE, SPOOL, TDSK, USER, SERVER and SYSTEM.An ″R″ or ″W″ next to the DASD counts means Read or Write cachingenabled, respectively.

• Communications: The type of control unit, number of communicationcontrol units, number of lines per control unit, and the line speed.

3. Software Configuration: This section contains pertinent software information.

• Driver: The tool used to simulate users.

• Think time distribution: The type of distribution used for the user thinktimes.

Bactrian This type of think time distribution represents a combination ofboth active and inactive user think times. The distributionincludes long think times that occur when the user is notactively issuing commands. Actual user data were collectedand used as input to the creation of the Bactrian distribution.This type of mechanism allows the transaction rate to varydepending on the command response times in themeasurement.

IOB This type of think time distribution represents the think timedefined by the IBM Office Benchmark (IOB V2.1) workload. Thethink time includes an average 2-second delay betweencommands issued by TPNS, the built-in think times that arepart of the IOB scripts, and the IOB script schedulingalgorithm. The average message rate per user stays constantacross all of the measurements. See “IBM Office Benchmark(IOB)” on page 88 for more details.

• CMS block size: The block size of the CMS minidisks.

• Virtual Machines: The virtual machines used in the measurement.

For each virtual machine, the table indicates the following: name,number used, type, size and mode, share of the system resourcesscheduled, number of pages reserved, and any other options that wereset.

4. Measurement Discussion: This contains an analysis of the performance datain the table and gives the overall performance findings.

5. Measurement Data: This contains the table of performance results. Thesedata were obtained or derived from the tools listed in “Tools Description” onpage 12.

There are several cases where the same information is reported from twosources because the sources calculate the value in a slightly differentmanner. For example, consider the external throughput rate measures, ETR(T) and ETR, that are based on the command rate calculated by TPNS andRTM, respectively. TPNS can directly count the command rate as it runs thecommands in the scripts. RTM, on the other hand, reports the command(transaction) rate that is determined by the CP scheduler, which has to makeassumptions about when transactions begin and end. This can make thecounts reported by RTM vary in meaning from run to run and vary from thevalues reported by TPNS. As a result, the analysis of the data is principallybased on the TPNS command rate. Furthermore, some values in the table

Measurement Information 11


(like TOT INT ADJ) are normalized to the TPNS command rate in an effort toget the most accurate performance measures possible.

Performance terms listed in the tables and discussed in this part of thedocument are defined in the glossary.

Tools DescriptionThe primary tools used to collect and evaluate the performance measurementsare listed below.

Licensed Programs:

RTM Real Time Monitor, records and reports performance data forVM systems.

TPNS Teleprocessing Network Simulator is a terminal and networksimulation tool.

TPNS Reduction ProgramReduces the TPNS log data to provide performance, load,and response time information.

VMPRF VM Performance Reporting Facility is the VM monitorreduction program.

Internal Tools:

FSTTAPE Reduces hardware monitor data for the 9121 processors.

Hardware Monitor Collects processor event and timing data.

REDFP Consolidates the QUERY FILEPOOL STATUS data from SFSmeasurements.


Migration: CMS-Intensive

Migration from VM/ESA 2.2.0 and TCP/IP 2.4

This chapter examines the performance effects of migrating from VM/ESA 2.2.0to VM/ESA 2.3.0 and from TCP/IP 2.4 to TCP/IP Function Level 310. The followingenvironments were measured: CMS-intensive, VSE guest, Telnet, and FTP.

CMS-IntensiveThe VM/ESA 2.3.0 performance results are similar to the corresponding VM/ESA2.2.0 results for the three measured CMS-intensive environments. ITR decreasesranging from 0.3% to 0.7% and external response time changes ranging from a3% decrease to a 1% increase were observed.

Although VM/ESA 2.3.0 includes a number of performance improvements (see“Performance Improvements” on page 3), none of them apply in a significantway to the measured CMS environments.

Measurement results and discussion for each of these three environments areprovided in the following sections.

9121-742 / MinidiskWorkload: FS8F0R

Hardware Configuration

Processor model: 9121-742Processors used: 4Storage:

Real: 1024MB (default MDC)Expanded: 1024MB (MDC BIAS 0.1)

Tape: 3480 (Monitor)

DASD:

Note: R next to the DASD counts means basic cache enabled; W means DASDfast write (and basic cache) enabled. RAMAC 2 refers to the RAMAC 2 ArraySubsystem with 256MB cache and drawers in 3390-3 format. With the RAMAC 2Array Subsystem, read and write caching are always enabled.

Communications:

Type ofDASD

ControlUnit

Numberof Paths PAGE SPOOL

- Number of Volumes -TDSK User Server System

3390-3 RAMAC 2 4 13 323390-2 3990-3 4 6 7 2 R3390-2 3990-2 4 16 6

Control Unit NumberLines per

Control Unit Speed

3088 1 NA 4.5MB



Software Configuration

Driver: TPNSThink time distribution: BactrianCMS block size: 4KB

Virtual Machines:

Measurement Discussion: The following table shows that VM/ESA 2.3.0 has verysimilar performance characteristics relative to VM/ESA 2.2.0 for this workloadand system configuration. External response time (AVG LAST(T)) improved by2%, while the internal throughput rate (ITR(H)) decreased by 0.3%. Pagingincreased slightly due to a 1-page increase in the average working set size.

VirtualMachine Number Type

MachineSize/Mode SHARE RESERVED Other Options

SMART 1 RTM 32MB/XA 3 % 500 QUICKDSP ONVSCSn 3 VSCS 64MB/XA 10000 1200 QUICKDSP ONVTAMXA 1 VTAM/VSCS 64MB/XA 10000 550 QUICKDSP ONWRITER 1 CP monitor 2MB/XA 100 QUICKDSP ONUnnnn 5800 Users 3MB/XC 100

Table 1 (Page 1 of 3). Minidisk-only CMS-intensive migration from VM/ESA 2.2.0 onthe 9121-742

ReleaseRun ID

2.2.0S49E5800

2.3.0S4AE5801 Difference %Difference

EnvironmentReal StorageExp. StorageUsersVTAMsVSCSsProcessors

1024MB1024MB

5800134

1024MB1024MB

5800134

Response TimeTRIV INTNONTRIV INTTOT INTTOT INT ADJAVG FIRST (T)AVG LAST (T)

0.0330.2480.1240.1920.2930.608

0.0330.2490.1240.1930.2920.597

0.0000.0010.0000.001

-0.001-0.012

0.00%0.40%0.00%0.52%

-0.50%-1.93%

ThroughputAVG THINK (T)ETRETR (T)ETR RATIOITR (H)ITREMUL ITRITRR (H)ITRR

26.57307.22198.32

1.549222.85

86.37137.20

1.0001.000

26.51309.18198.54

1.557222.30

86.63137.47

0.9981.003

-0.061.960.23

0.008-0.550.270.27

-0.0020.003

-0.22%0.64%0.11%0.52%

-0.25%0.31%0.20%

-0.25%0.31%

Proc. UsagePBT/CMD (H)PBT/CMDCP/CMD (H)CP/CMDEMUL/CMD (H)EMUL/CMD

17.94917.951

7.0786.656

10.87111.295

17.99417.981

7.0676.648

10.92611.332

0.0440.030

-0.011-0.0080.0550.037

0.25%0.17%

-0.15%-0.11%0.51%0.33%




ReleaseRun ID

2.2.0S49E5800



1024MB1024MB

5800134

1024MB1024MB

5800134

Processor Util.TOTAL (H)TOTALUTIL/PROC (H)UTIL/PROCTOTAL EMUL (H)TOTAL EMULMASTER TOTAL (H)MASTER TOTALMASTER EMUL (H)MASTER EMULTVR(H)TVR

355.97356.00

88.9989.00

215.59224.00

91.0791.0034.2836.00

1.651.59

357.26357.00

89.3189.25

216.94225.00

88.6689.0034.4936.00

1.651.59

1.291.000.320.251.341.00

-2.41-2.000.210.000.000.00

0.36%0.28%0.36%0.28%0.62%0.45%

-2.65%-2.20%0.61%0.00%

-0.26%-0.16%

StorageNUCLEUS SIZE (V)TRACE TABLE (V)WKSET (V)PGBLPGSPGBLPGS/USERTOT PAGES/USER (V)FREEPGSFREE UTILSHRPGS

2844KB650KB

77230K39.7191

173210.92

2158

2452KB650KB

78230K39.7193

175550.92

2170

-392KB0KB

10K0.0

2234

0.0012

-13.78%0.00%1.30%0.00%0.00%1.05%1.35%0.26%0.56%

PagingREADS/SECWRITES/SECPAGE/CMDPAGE IO RATE (V)PAGE IO/CMD (V)XSTOR IN/SECXSTOR OUT/SECXSTOR/CMDFAST CLR/CMD

1059797

9.359341.000

1.719555

154110.569

8.890

1107834

9.776334.400

1.684529

156210.532

8.990

4837

0.417-6.600-0.035

-2621

-0.0370.101

4.53%4.64%4.46%

-1.94%-2.05%-4.68%1.36%

-0.35%1.13%

QueuesDISPATCH LISTELIGIBLE LIST

112.960.02

109.530.04

-3.440.02

-3.04%100.00%

I/OVIO RATEVIO/CMDRIO RATE (V)RIO/CMD (V)NONPAGE RIO/CMD (V)DASD RESP TIME (V)MDC REAL SIZE (MB)MDC XSTOR SIZE (MB)MDC READS (I/Os)MDC WRITES (I/Os)MDC AVOIDMDC HIT RATIO

17939.041

6973.5151.795

21.30032.163.1569

27529

0.92

17979.051

6903.4751.791

21.90032.163.8572

27533

0.93

40.010

-7-0.039-0.0040.600

0.00.7

304

0.01

0.22%0.11%

-1.00%-1.12%-0.23%2.82%0.12%1.10%0.53%0.00%0.76%1.09%

Migration from VM/ESA 2.2.0 and TCP/IP 2.4 15



ReleaseRun ID

2.2.0S49E5800



1024MB1024MB

5800134

1024MB1024MB

5800134

PRIVOPsPRIVOP/CMDDIAG/CMDDIAG 04/CMDDIAG 08/CMDDIAG 0C/CMDDIAG 14/CMDDIAG 58/CMDDIAG 98/CMDDIAG A4/CMDDIAG A8/CMDDIAG 214/CMDDIAG 270/CMDSIE/CMDSIE INTCPT/CMDFREE TOTL/CMD

20.64624.451

0.9670.7350.2120.0241.2490.2113.5582.678

12.5220.921

55.46737.16345.326

20.62623.859

0.8880.7370.1920.0251.2500.2093.5822.683

11.9760.941

55.40337.12044.892

-0.020-0.591-0.0780.002

-0.0190.0000.001

-0.0020.0240.005

-0.5460.020

-0.064-0.043-0.435

-0.10%-2.42%-8.10%0.23%

-9.08%0.35%0.07%

-1.18%0.67%0.18%

-4.36%2.14%

-0.11%-0.11%-0.96%

VTAM MachinesWKSET (V)TOT CPU/CMD (V)CP CPU/CMD (V)VIRT CPU/CMD (V)DIAG 98/CMD (V)

41292.94981.31941.6304

0.211

41402.98001.32631.6537

0.209

110.03020.00690.0233-0.002

0.27%1.02%0.52%1.43%

-1.13%

Note: T=TPNS, V=VMPRF, H=Hardware Mon i to r , Unmarked=RTM



9121-480 / MinidiskWorkload: FS8F0R



Real: 256MB (default MDC)Expanded: 0MB


DASD:


Communications:



Virtual Machines:

Measurement Discussion: External response time (AVG LAST(T)) increased by1%, while internal throughput (ITR(H)) decreased by 0.5%. These results aresimilar to what was observed for the 9121-742 environment (see the previoussection).

Type ofDASD

ControlUnit



3390-3 RAMAC 2 4 8 163390-2 3990-2 4 16 63390-2 3990-3 2 2 R3390-2 3990-3 4 2


Control Unit Speed

3088-08 1 NA 4.5MB



SMART 1 RTM 32MB/XA 3 % 400 QUICKDSP ONVTAMXA 1 VTAM/VSCS 64MB/XA 10000 560 QUICKDSP ONWRITER 1 CP monitor 2MB/XA 100 QUICKDSP ONUnnnn 2040 Users 3MB/XC 100




ReleaseRun ID

2.2.0L29E2043

2.3.0L2AE2045 Difference %Difference


256MB0MB2040

102

256MB0MB2040

102


0.1310.4370.3330.2980.2700.381

0.1350.4510.3430.3080.2690.385

0.0040.0140.0100.009

-0.0010.004

3.05%3.20%3.00%3.12%

-0.55%1.05%


26.1864.1571.580.89679.2635.5353.001.0001.000

26.1464.1171.460.89778.9035.4252.970.9950.997

-0.04-0.04-0.120.001-0.36-0.11-0.04

-0.005-0.003

-0.13%-0.06%-0.17%0.11%

-0.45%-0.30%-0.07%-0.45%-0.30%


25.23425.286

8.9188.382

16.31616.904

25.34925.330

8.9808.397

16.37016.933

0.1150.0440.0620.0150.0530.029

0.46%0.17%0.69%0.17%0.33%0.17%


180.63181.00

90.3290.50

116.79121.00

90.0590.0051.5854.00

1.551.50

181.14181.00

90.5790.50

116.97121.00

90.2090.0051.5554.00

1.551.50

0.510.000.250.000.180.000.160.00

-0.030.000.000.00

0.28%0.00%0.28%0.00%0.15%0.00%0.17%0.00%

-0.06%0.00%0.13%0.00%


2388KB350KB

8254133

26.5172

61960.95

1503

2452KB350KB

8354117

26.5174

62680.94

1488

64KB0KB

1-160.0

272

-0.01-15

2.68%0.00%1.22%

-0.03%-0.03%1.16%1.16%

-1.15%-1.00%




ReleaseRun ID

2.2.0L29E2043

2.3.0L2AE2045 Difference %Difference


256MB0MB2040

102

256MB0MB2040

102


715469

16.541196.200

2.74100

0.0008.773

722472

16.709198.900

2.78300

0.0008.858

73

0.1692.7000.043

00

0.0000.085

0.98%0.64%1.02%1.38%1.55%

nanana

0.97%


45.480.00

45.440.00

-0.040.00

-0.08%na


7119.933

4005.5882.847

18.60041.7

0.0205

9.80192

0.94

7099.922

4015.6122.828

18.50040.9

0.0206

9.91194

0.94

-2-0.011

10.024

-0.019-0.100

-0.80.0

10.11

20.00

-0.28%-0.11%0.25%0.42%

-0.66%-0.54%-1.90%

na0.49%1.12%1.04%0.00%


13.89726.628

2.2500.7320.2120.0241.2511.1343.5692.663

12.4950.921

53.93834.52149.733

13.87026.051

2.2450.7330.1920.0241.2501.1043.5932.666

11.9270.941

53.93434.51849.484

-0.027-0.577-0.0050.001

-0.0200.000

-0.001-0.0300.0240.003

-0.5690.020

-0.004-0.003-0.249

-0.19%-2.17%-0.21%0.19%

-9.29%0.39%

-0.07%-2.68%0.66%0.12%

-4.55%2.18%

-0.01%-0.01%-0.50%


5603.97371.48242.4913

1.134

5733.98061.49272.4879

1.103

130.00690.0103

-0.0034-0.031

2.32%0.17%0.69%

-0.14%-2.74%




9121-480 / SFSWorkload: FS8FMAXR





DASD:


Communications:



Virtual Machines:

Measurement Discussion: External response time (AVG LAST(T)) improved by3%, while internal throughput (ITR(H)) decreased by 0.7%. The ITR decrease issomewhat larger than the 0.5% decrease observed for the 9121-480 minidiskenvironment (see the previous section) due to the fact that there was,additionally, some growth in SFS server CPU usage.

Type ofDASD

ControlUnit



3390-3 RAMAC 2 4 8 163390-2 3990-2 4 16 63390-2 3990-3 2 2 R3390-2 3990-3 4 2


Control Unit Speed

3088-08 1 NA 4.5MB



CRRSERV1 1 SFS 16MB/XC 100ROSERV1 1 SFS 64MB/XC 100 QUICKDSP ONRWSERVn 2 SFS 64MB/XC 1500 1300 QUICKDSP ONSMART 1 RTM 32MB/XA 3 % 400 QUICKDSP ONVTAMXA 1 VTAM/VSCS 64MB/XA 10000 512 QUICKDSP ONWRITER 1 CP monitor 2MB/XA 100 QUICKDSP ONUnnnn 1720 Users 3MB/XC 100



Table 3 (Page 1 of 3). SFS CMS-intensive migration from VM/ESA 2.2.0 on the9121-480

ReleaseRun ID

2.2.0L29S1722

2.3.0L2AS1721 Difference %Difference


256MB0MB1720

102

256MB0MB1720

102


0.1270.4740.3570.3160.2550.384

0.1300.4650.3540.3120.2510.373

0.003-0.009-0.003-0.004-0.004-0.011

2.36%-1.90%-0.84%-1.23%-1.76%-2.74%


26.1653.2460.220.88466.7929.5444.821.0001.000

26.2053.0160.200.88166.3229.2244.440.9930.989

0.04-0.23-0.02

-0.004-0.46-0.32-0.38

-0.007-0.011

0.13%-0.43%-0.04%-0.40%-0.69%-1.10%-0.84%-0.69%-1.10%


29.94729.88910.87210.12919.07419.760

30.15630.23210.99310.46519.16219.767

0.2090.3430.1210.3360.0880.007

0.70%1.15%1.11%3.32%0.46%0.04%


180.35180.00

90.1790.00

114.87119.00

89.9790.0051.8254.00

1.571.51

181.54182.00

90.7791.00

115.36119.00

90.5591.0051.9054.00

1.571.53

1.202.000.601.000.490.000.581.000.080.000.000.02

0.66%1.11%0.66%1.11%0.43%0.00%0.64%1.11%0.16%0.00%0.24%1.11%


2388KB350KB

7955319

32.2157

53850.95

1706

2452KB350KB

8155389

32.2159

53770.95

1718

64KB0KB

270

0.02

-80.00

12

2.68%0.00%2.53%0.13%0.13%1.27%

-0.15%0.15%0.70%




ReleaseRun ID

2.2.0L29S1722



256MB0MB1720

102

256MB0MB1720

102


588388

16.206148.100

2.45900

0.0008.518

605397

16.644154.600

2.56800

0.0008.654

179

0.4386.5000.109

00

0.0000.136

2.89%2.32%2.70%4.39%4.43%

nanana

1.60%


41.200.00

41.140.00

-0.050.00

-0.13%na


61010.129

3626.0113.552

17.00069.5

0.0161

15134

0.83

60910.116

3676.0963.528

17.00067.0

0.0162

15135

0.83

-1-0.013

50.085

-0.0240.000

-2.50.0

101

0.00

-0.16%-0.13%1.38%1.42%

-0.67%0.00%

-3.60%na

0.62%0.00%0.75%0.00%


20.50124.847

2.4890.7360.2370.0251.2501.3871.9852.456

11.9920.920

61.78742.01553.169

20.67324.351

2.4880.7360.2170.0251.2491.3471.9922.457

11.5220.941

62.14142.25653.171

0.172-0.497-0.0020.000

-0.0200.0000.000

-0.0400.0070.001

-0.4700.0210.3540.2410.002

0.84%-2.00%-0.06%0.05%

-8.50%0.34%

-0.03%-2.87%0.38%0.05%

-3.92%2.26%0.57%0.57%0.00%


5094.22501.57752.6476

1.387

4954.21731.56882.6485

1.347

-14-0.0077-0.00870.0009-0.040

-2.75%-0.18%-0.55%0.03%

-2.86%



The SFS counts and timings in the following two tables are provided tosupplement the information provided above. These were acquired by issuing theQUERY FILEPOOL STATUS command once at the beginning of the measurementinterval and once at the end. The QUERY FILEPOOL STATUS information wasobtained for each SFS file pool server and the CRR recovery server. The countsand timings for each server were added together. A description of the QUERYFILEPOOL STATUS output can be found in VM/ESA: CMS File Pool Planning,Administration, and Operation.

Table 4 consists of counts and timings that are normalized by the number ofcommands (as determined by TPNS). The beginning values were subtractedfrom the ending values and divided by the number of commands in themeasurement interval. Counts and timings that have a value of zero for allmeasurements are not shown. A zero entry indicates that at least oneoccurrence was counted but the result of normalizing per command is so smallthat it rounds to zero.


ReleaseRun ID

2.2.0L29S1722



256MB0MB1720

102

256MB0MB1720

102

SFS ServersWKSET (V)TOT CPU/CMD (V)CP CPU/CMD (V)VIRT CPU/CMD (V)FP REQ/CMD(Q)IO/CMD (Q)IO TIME/CMD (Q)SFS TIME/CMD (Q)

33643.40401.49441.9096

1.1141.6140.0230.035

33603.46981.53191.9379

1.1511.6440.0230.034

-40.06580.03750.0283

0.0370.0300.000

-0.001

-0.12%1.93%2.51%1.48%3.32%1.86%0.00%

-2.86%

Note: T=TPNS, V=VMPRF, H=Hardware Moni tor , Q=Query F i lepool Counters ,U n m a r k e d = R T M



Table 4. SFS CMS-intensive migration from VM/ESA 2.2.0 on the 9121-480

ReleaseRun ID

2.2.0L29S1722



256MB0MB1720

102

256MB0MB1720

102

Close File RequestsCommit RequestsConnect RequestsDelete File RequestsLock RequestsOpen File New RequestsOpen File Read RequestsOpen File Replace RequestsOpen File Write RequestsQuery File Pool RequestsQuery User Space RequestsRead File RequestsRefresh Directory RequestsRename RequestsUnlock RequestsWrite File Requests

0.36190.01630.00780.07340.02460.00330.21640.12100.02120.00000.02120.14410.02270.00490.02460.0507

0.37960.01640.00790.07360.02460.00330.23410.12100.02120.00000.02130.14420.02290.00490.02460.0509

0.01770.00010.00010.00020.00000.00000.01770.00000.00000.00000.00010.00010.00020.00000.00000.0002

4.89%0.61%1.28%0.27%0.00%0.00%8.18%0.00%0.00%

na0.47%0.07%0.88%0.00%0.00%0.39%

Total File Pool RequestsFile Pool Request Service TimeLocal File Pool Requests

1.114335.1515

1.1143

1.150634.2354

1.1506

0.0363-0.91610.0363

3.26%-2.61%3.26%

Begin LUWsAgent Holding Time (msec)SAC Calls

0.4451110.7923

5.4834

0.4633106.4140

5.6300

0.0182-4.37830.1466

4.09%-3.95%2.67%

Catalog Lock ConflictsTotal Lock ConflictsLock Wait Time (msec)

0.00180.00180.1426

0.00120.00120.0626

-0.0006-0.0006-0.0800

-33.33%-33.33%-56.10%

File Blocks ReadFile Blocks WrittenCatalog Blocks ReadCatalog Blocks WrittenControl Minidisk Blocks WrittenLog Blocks WrittenTotal DASD Block Transfers

0.89950.49660.51950.26960.05110.46152.6976

0.91750.49840.52690.27330.05270.46362.7324

0.01800.00180.00740.00370.00160.00210.0348

2.00%0.36%1.42%1.37%3.13%0.46%1.29%

BIO Requests to Read File BlockBIO Requests to Write File BlocksBIO Requests to Read Catalog BlksBIO Requests to Write Catalog BlksBIO Requests to Write Ctl Mdsk BlksBIO Requests to Write Log BlocksTotal BIO RequestsTotal BIO Request Time (msec)

0.38800.17900.51950.22310.00210.40261.7142

23.1710

0.40570.17920.52690.22390.00210.40461.7425

22.8600

0.01770.00020.00740.00080.00000.00200.0283

-0.3110

4.56%0.11%1.42%0.36%0.00%0.50%1.65%

-1.34%

I/O Requests to Read File BlocksI/O Requests to Write File BlocksI/O Requests to Read Catalog BlksI/O Requests to Write Catalog BlksI/O Requests to Write Ctl Mdsk BlksI/O Requests to Write Log BlocksTotal I/O Requests

0.26370.19470.51950.22930.00380.40291.6138

0.28180.19560.52690.23070.00400.40501.6439

0.01810.00090.00740.00140.00020.00210.0301

6.86%0.46%1.42%0.61%5.26%0.52%1.87%

Get Logname RequestsGet LUWID RequestsTotal CRR RequestsCRR Request Service Time (msec)Log I/O Requests

0.00320.00320.00650.04950.0065

0.00330.00330.00660.04300.0066

0.00010.00010.0001

-0.00650.0001

3.13%3.13%1.54%

-13.13%1.54%

Note: Query Filepool Counters — normalized by command



Table 5 consists of derived relationships that were calculated from acombination of two or more individual counts or timings. See the glossary fordefinitions of these derived values.

Table 6 compares the VM/ESA 2.3.0 SFS measurement to the correspondingVM/ESA 2.3.0 minidisk-only measurement from Table 2 on page 18.

Table 5. SFS CMS-intensive migration from VM/ESA 2.2.0 on the 9121-480

ReleaseRun ID

2.2.0L29S1722



256MB0MB1720

102

256MB0MB1720

102

Agents HeldAgents In-callAvg LUW Time (msec)Avg File Pool Request Time (msec)Avg Lock Wait Time (msec)SAC Calls / FP Request

6.72.1

248.931.579.24.92

6.42.1

229.729.852.24.89

-0.3-0.1

-19.2-1.8

-27.1-0.03

-3.99%-2.64%-7.72%-5.68%

-34.15%-0.57%

Deadlocks (delta)Rollbacks Due to Deadlock (delta)Rollback Requests (delta)LUW Rollbacks (delta)

000

853

000

840

000

-13

nanana

-1.52%

Checkpoints Taken (delta)Checkpoint Duration (sec)Seconds Between CheckpointsCheckpoint Util ization

342.8

56.55.0

352.7

54.95.0

1-0.1-1.60.0

2.94%-3.50%-2.75%-0.63%

BIO Request Time (msec)Blocking Factor (Blocks/BIO)Chaining Factor (Blocks/IO)

13.521.571.67

13.121.571.66

-0.40-0.01-0.01

-2.94%-0.36%-0.56%

Note: Query Filepool Counters — derived results



Table 6 (Page 1 of 3). Minidisk to SFS comparison for VM/ESA 2.3.0 on the9121-480

File SystemReleaseRun ID

Minidisk2.3.0

L2AE2045

SFS2.3.0

L2AS1721Difference %Difference


256MB0MB2040

102

256MB0MB1720

102

-320 -15.69%


0.1350.4510.3430.3080.2690.385

0.1300.4650.3540.3120.2510.373

-0.0050.0140.0110.004

-0.018-0.012

-3.70%3.10%3.21%1.29%

-6.88%-3.12%


26.1464.1171.460.89778.9035.4252.971.0001.000

26.2053.0160.200.88166.3229.2244.440.8410.825

0.06-11.10-11.26-0.017-12.58

-6.20-8.53

-0.159-0.175

0.21%-17.31%-15.75%

-1.86%-15.94%-17.50%-16.10%-15.94%-17.50%


25.34925.330

8.9808.397

16.37016.933

30.15630.23210.99310.46519.16219.767

4.8074.9022.0142.0682.7932.834

18.96%19.35%22.42%24.63%17.06%16.73%


181.14181.00

90.5790.50

116.97121.00

90.2090.0051.5554.00

1.551.50

181.54182.00

90.7791.00

115.36119.00

90.5591.0051.9054.00

1.571.53

0.411.000.200.50

-1.61-2.000.351.000.360.000.030.03

0.22%0.55%0.22%0.55%

-1.38%-1.65%0.38%1.11%0.69%0.00%1.62%2.24%


2452KB350KB

8354117

26.5174

62680.94

1488

2452KB350KB

8155389

32.2159

53770.95

1718

0KB0KB

-21272

5.7-15

-8910.01230

0.00%0.00%

-2.41%2.35%

21.39%-8.62%

-14.22%1.37%

15.46%





Minidisk2.3.0

L2AE2045

SFS2.3.0



256MB0MB2040

102

256MB0MB1720

102

-320 -15.69%


722472

16.709198.900

2.78300

0.0008.858

605397

16.644154.600

2.56800

0.0008.654

-117-75

-0.065-44.300

-0.21500

0.000-0.204

-16.20%-15.89%

-0.39%-22.27%

-7.74%nanana

-2.31%


45.440.00

41.140.00

-4.300.00

-9.47%na


7099.922

4015.6122.828

18.50040.9

0.0206

9.91194

0.94

60910.116

3676.0963.528

17.00067.0

0.0162

15135

0.83

-1000.194

-340.4840.700

-1.50026.1

0.0-44

5.09-59

-0.11

-14.10%1.95%

-8.48%8.63%

24.75%-8.11%63.86%

na-21.36%51.36%

-30.41%-11.70%


13.87026.051

2.2450.7330.1920.0241.2501.1043.5932.666

11.9270.941

53.93434.51849.484

20.67324.351

2.4880.7360.2170.0251.2491.3471.9922.457

11.5220.941

62.14142.25653.171

6.803-1.7000.2420.0030.0250.0000.0000.243

-1.601-0.210-0.4040.0008.2067.7383.687

49.04%-6.53%10.79%

0.38%12.86%

0.89%-0.03%22.05%

-44.55%-7.86%-3.39%0.02%

15.22%22.42%

7.45%


5733.98061.49272.4879

1.103

4954.21731.56882.6485

1.347

-780.23670.07610.1606

0.244

-13.61%5.95%5.10%6.46%

22.16%



These results show the normal relationship between the minidisk and SFSimplementations of the FS8F workload that has been observed in the past.



Minidisk2.3.0

L2AE2045

SFS2.3.0



256MB0MB2040

102

256MB0MB1720

102

-320 -15.69%


nananananananana

33603.46981.53191.9379

1.1511.6440.0230.034



Migration: VSE/ESA Guest

VSE/ESA GuestThis section examines the performance impact of migrating a VSE/ESA 2.1.0guest from VM/ESA 2.2.0 to VM/ESA 2.3.0 All measurements were made on a9121-320 using the DYNAPACE workload. DYNAPACE is a batch workload and ischaracterized by heavy I/O. See Appendix A, “Workloads” on page 78 for adescription of this workload.

Measurements were obtained with the VSE/ESA* system run as a V=R guestand as a V=V guest. The V=R guest environment had dedicated DASD with I/Oassist. The V=V guest environment was configured with full pack minidiskDASD with minidisk caching (MDC) active.

Workload: DYNAPACE


Processor models: 9121-320Storage

Real: 256MBExpanded: 0MB

DASD:


VSE version: 2.1.0 (using the standard dispatcher)

Virtual Machines:

Additional Information: The VM system used for these guest measurements hasa 96MB V=R area defined. For measurements with V=V guests, the V=R areais configured, but not used. There is 256MB total real storage on the processorso 160MB of useable storage is available for the VM system and V=V guest.For the V=V measurements, it is this effective real storage size that is shown inthe measurement results tables.

Measurement Discussion: The measured internal throughput rate (ITR(H))decreased somewhat relative to VM/ESA 2.2.0. The amount of decrease was0.8% for the V=R environment and 1.0% for the V=V environment. Elapsedtimes were equivalent within measurement variability.

Type ofDASD

ControlUnit


- Number of Volumes -TDSK VSAM VSE Sys. VM Sys.

3380-A 3880-03 2 13390-2 3990-02 4 10 23380-K 3990-03 4 10



VSEVR 1 VSE V=R 96MB/ESA 100 IOASSIST ONCCWTRANS OFF

orVSEVV 1 VSE V=V 96MB/ESA 100 IOASSIST OFF

SMART 1 RTM 16MB/370 100WRITER 1 CP monitor 2MB/XA 100



Table 7 (Page 1 of 2). VSE/ESA V = R guest migration from VM/ESA 2.2.0 on the9121-320

ReleaseRun ID

2.2.0L1R98PF2

2.3.0L1RA8PF2 Difference %Difference

EnvironmentIML ModeReal StorageExp. StorageVM ModeVM SizeGuest SettingVSE SupervisorProcessors

ESA256MB

0MBESA96M

V = RESA

1

ESA256MB

0MBESA96M

V = RESA

1

Throughput (Min)Elapsed Time (C)ETR (C)ITR (H)ITRITRR (H)ITRR

874.07.69

18.9818.751.0001.000

871.07.72

18.8318.820.9921.003

-3.00.03

-0.150.06

-0.0080.003

-0.34%0.34%

-0.79%0.34%

-0.79%0.34%

Proc. Usage (Sec)PBT/CMD (H)PBT/CMDCP/CMD (H)CP/CMDEMUL/CMD (H)EMUL/CMD

3.1623.1990.2760.3122.8852.887

3.1873.1880.2910.2332.8962.955

0.025-0.0110.014

-0.0790.0110.068

0.80%-0.34%5.14%

-25.26%0.38%2.35%

Processor Util.TOTAL (H)TOTALTOTAL EMUL (H)TOTAL EMULTVR(H)TVR

40.5141.0036.9737.00

1.101.11

40.9841.0037.2438.00

1.101.08

0.460.000.271.000.00

-0.03

1.15%0.00%0.73%2.70%0.41%

-2.63%

StorageNUCLEUS SIZE (V)TRACE TABLE (V)PGBLPGSFREEPGSFREE UTILSHRPGS

2820KB200KB38541

890.56

3494

2884KB200KB38532

850.61

3495

64KB0KB

-9-4

0.051

2.27%0.00%

-0.02%-4.49%9.42%0.03%

PagingPAGE/CMDXSTOR/CMDFAST CLR/CMD

0.0000.0000.000

0.0000.0000.000

0.0000.0000.000

nanana

I/OVIO RATEVIO/CMDRIO RATE (V)RIO/CMD (V)DASD IO TOTAL (V)DASD IO RATE (V)DASD IO/CMD (V)MDC REAL SIZE (MB)MDC XSTOR SIZE (MB)MDC READS (I/Os)MDC WRITES (I/Os)MDC AVOIDMDC HIT RATIO

1.0007.8042.000

15.607350630389.59

3040.188.10.0

0.030.030.010.30

1.0007.7772.000

15.554350840389.82

3031.568.00.0

0.030.030.010.32

0.000-0.0270.000

-0.054210

0.23-8.62

-0.10.0

000

0.02

0.00%-0.34%0.00%

-0.34%0.06%0.06%

-0.28%-0.97%

na0.00%0.00%0.00%6.67%



Table 7 (Page 2 of 2). VSE/ESA V = R guest migration from VM/ESA 2.2.0 on the9121-320

ReleaseRun ID

2.2.0L1R98PF2

2.3.0L1RA8PF2 Difference %Difference


ESA256MB

0MBESA96M

V = RESA

1

ESA256MB

0MBESA96M

V = RESA

1

PRIVOPsPRIVOP/CMD (R)DIAG/CMD (R)SIE/CMDSIE INTCPT/CMDFREE TOTL/CMD

10.791606.378

2739.0542273.414

546.250

10.675607.677

2784.0892310.794

528.821

-0.1161.300

45.03637.380

-17.429

-1.07%0.21%1.64%1.64%

-3.19%

Note: V=VMPRF, H=Hardware Moni to r , C=VSE conso le , Unmarked=RTM

Table 8 (Page 1 of 2). VSE/ESA V = V guest migration from VM/ESA 2.2.0 on the9121-320

ReleaseRun ID

2.2.0L1V98PF2

2.3.0L1VA8PF2 Difference %Difference


ESA160MB

0MBESA96M

V = RESA

1

ESA160MB

0MBESA96M

V = RESA

1

Throughput (Min)Elapsed Time (C)ETR (C)ITR (H)ITRITRR (H)ITRR

484.013.8814.7614.771.0001.000

483.013.9114.6114.650.9900.992

-1.00.03

-0.15-0.13

-0.010-0.008

-0.21%0.21%

-1.03%-0.85%-1.03%-0.85%

Proc. Usage (Sec)PBT/CMD (H)PBT/CMDCP/CMD (H)CP/CMDEMUL/CMD (H)EMUL/CMD

4.0654.0621.1240.9942.9413.068

4.1074.0971.1571.0352.9513.062

0.0420.0350.0330.0410.010

-0.006

1.04%0.86%2.92%4.13%0.32%

-0.21%

Processor Util.TOTAL (H)TOTALTOTAL EMUL (H)TOTAL EMULTVR(H)TVR

94.0694.0068.0671.00

1.381.32

95.2495.0068.4271.00

1.391.34

1.181.000.360.000.010.01

1.25%1.06%0.53%0.00%0.72%1.06%



Table 8 (Page 2 of 2). VSE/ESA V = V guest migration from VM/ESA 2.2.0 on the9121-320

ReleaseRun ID

2.2.0L1V98PF2

2.3.0L1VA8PF2 Difference %Difference


ESA160MB

0MBESA96M

V = RESA

1

ESA160MB

0MBESA96M

V = RESA

1

StorageNUCLEUS SIZE (V)TRACE TABLE (V)PGBLPGSFREEPGSFREE UTIL

2820KB200KB38458

1080.62

2884KB200KB38459

1070.62

64KB0KB

1-1

0.00

2.27%0.00%0.00%

-0.93%0.18%

PagingPAGE/CMDXSTOR/CMDFAST CLR/CMD

47.5360.000

280.893

112.1250.000

276.000

64.5890.000

-4.893

135.88%na

-1.74%

I/OVIO RATEVIO/CMDRIO RATE (V)RIO/CMD (V)DASD IO TOTAL (V)DASD IO RATE (V)DASD IO/CMD (V)MDC REAL SIZE (MB)MDC XSTOR SIZE (MB)MDC READS (I/Os)MDC WRITES (I/Os)MDC AVOIDMDC HIT RATIO

724.0003128.714

316.0001365.571

151261315.13

1361.80112.4

0.0443219415

0.86

722.0003113.625

322.0001388.625

153866320.55

1382.39112.6

0.0442218407

0.85

-2.000-15.089

6.00023.054

26055.43

20.590.20.0-1-1-8

-0.01

-0.28%-0.48%1.90%1.69%1.72%1.72%1.51%0.19%

na-0.23%-0.46%-1.93%-1.16%

PRIVOPsPRIVOP/CMD (R)DIAG/CMD (R)SIE/CMDSIE INTCPT/CMDFREE TOTL/CMD

3126.116452.670

13612.50011842.875

3980.036

3117.492450.594

13618.87511848.421

4019.250

-8.624-2.0766.3755.546

39.214

-0.28%-0.46%0.05%0.05%0.99%

Note: V=VMPRF, H=Hardware Moni to r , C=VSE conso le , Unmarked=RTM


Migration: TCP/IP

TCP/IPTelnet and FTP measurements were obtained to evaluate the performanceeffects of migrating from TCP/IP 2.4 to TCP/IP 310. The results show a 3.7%decrease in TCPIP virtual machine processor usage. This improvement resultedfrom pathlength improvements that were made to the TCP/IP stack.

TelnetWorkload: FS8F0R





DASD:


Communications:

16 Mbit IBM Token Ring3172-3 Interconnect Controller



Virtual Machines:

Type ofDASD

ControlUnit



3390-3 RAMAC 2 4 8 163390-2 3990-2 4 16 63390-2 3990-3 2 2 R3390-2 3990-3 4 2



TCPIP 1 TCP/IP 256MB/XA 10000 2700 QUICKDSP ONSMART 1 RTM 32MB/XA 3 % 400 QUICKDSP ONWRITER 1 CP monitor 2MB/XA 100 QUICKDSP ONUnnnn 1800 Users 3MB/XC 100


Migration: TCP/IP

Measurement Discussion: Relative to TCP/IP 2.4, external response time (AVGLAST(T)) improved by 8% while internal throughput rate (ITR(H)) improved by0.6%. These results are due to reduced processor usage in the TCPIP virtualmachine, as shown by TCPIP VIRT CPU/CMD(V) in Table 9. This and otherperformance improvements are described in “Performance Improvements” onpage 3.

These measurements were run with the size of each TCP/IP buffer pool set to beslightly larger than maximum requirements, as determined by the NETSTATPOOLSIZE command. This is the “Trimmed” configuration in Table 21 onpage 59. Because of this, these results do not reflect the additional benefitsfrom the “Reduced TCP/IP Real Storage Usage” performance improvement.That improvement is discussed in “Reduced TCP/IP Real Storage Requirements”on page 58.

Table 9 (Page 1 of 3). Telnet migration on a 9121-480

TCP/IP ReleaseVM/ESA ReleaseRun ID

2.42.3.0

L2AE1803

3102.3.0

L2AE1804Difference %Difference


256MB0MB1800

na02

256MB0MB1800

na02


0.1220.8370.2450.2270.3310.438

0.1110.8120.2320.2140.2990.402

-0.011-0.025-0.013-0.013-0.033-0.036

-9.02%-2.99%-5.31%-5.60%-9.95%-8.32%


24.5358.2862.870.92769.8432.4152.761.0001.000

24.5058.1962.970.92470.2432.4753.281.0061.002

-0.03-0.090.10

-0.0030.400.060.52

0.0060.002

-0.12%-0.15%0.16%

-0.31%0.57%0.19%0.98%0.57%0.19%


28.63528.62911.68810.97516.94717.655

28.47428.42511.76711.11616.70717.309

-0.162-0.2040.0790.141

-0.240-0.346

-0.56%-0.71%0.67%1.29%

-1.42%-1.96%


Migration: TCP/IP



2.42.3.0

L2AE1803

3102.3.0



256MB0MB1800

na02

256MB0MB1800

na02


180.04180.00

90.0290.00

106.55111.00

90.5791.0044.0446.00

1.691.62

179.31179.00

89.6589.50

105.21109.00

90.2890.0043.4245.00

1.701.64

-0.73-1.00-0.37-0.50-1.34-2.00-0.28-1.00-0.62-1.000.010.02

-0.41%-0.56%-0.41%-0.56%-1.26%-1.80%-0.31%-1.10%-1.41%-2.17%0.86%1.27%


2452KB350KB

8655511

30.8179

53490.96917

2452KB350KB

8555510

30.8179

53550.96961

0KB0KB

-1-1

0.006

0.0044

0.00%0.00%

-1.16%0.00%0.00%0.00%0.11%

-0.11%4.80%


690410

17.496170.900

2.71800

0.0008.891

692414

17.563171.700

2.72700

0.0008.909

24

0.0670.8000.008

00

0.0000.018

0.29%0.98%0.39%0.47%0.31%

nanana

0.20%


23.400.00

22.330.00

-1.070.00

-4.57%na


88013.996

6159.7827.063

18.10042.4

0.0181

8.61171

0.94

88414.038

6189.8147.087

18.10042.0

0.0181

8.63171

0.94

40.041

30.0320.0240.000

-0.40.0

00.02

00.00

0.45%0.29%0.49%0.33%0.34%0.00%

-1.00%na

0.00%0.23%0.00%0.00%


Migration: TCP/IP



2.42.3.0

L2AE1803

3102.3.0



256MB0MB1800

na02

256MB0MB1800

na02


1.61836.101

2.4990.7320.1920.0241.2485.1613.5932.666

11.9220.940

65.59343.94753.600

1.62636.180

2.4960.7360.1920.0251.2505.1903.5912.685

11.9100.940

65.72644.69453.705

0.0090.079

-0.0030.0040.0000.0000.0020.029

-0.0010.018

-0.0120.0000.1340.7470.105

0.54%0.22%

-0.10%0.57%0.26%0.95%0.17%0.57%

-0.04%0.69%

-0.10%0.02%0.20%1.70%0.20%

TCPIP MachineWKSET (V)TOT CPU/CMD (V)CP CPU/CMD (V)VIRT CPU/CMD (V)DIAG 98/CMD (V)

27005.55802.40303.1550

5.164

27005.35502.42602.9290

5.190

0-0.20300.0230

-0.22600.026

0.00%-3.65%0.96%

-7.16%0.50%

Note: T=TPNS, V=VMPRF, H=Hardware Mon i to r ,Unmarked=RTM

FTPMeasurement Description: The measured system consisted of a 9121-480(2-way) processor with 256MB of central storage and no expanded storage. Itwas running VM/ESA 2.3.0 with TCP/IP 2.4 or TCP/IP 310. This system wasattached to a 16Mbit IBM Token Ring through a 3172-3 Interconnect Controller.The TCPIP server was run with the “trimmed” buffer pool sizes listed in Table 21on page 59 and with a packet (MTU) size of 4000 bytes. File transfer wasto/from an RS/6000 model 520 on the same token ring. The RS/6000 was runningAIX 3.2.4.

The workload consisted of “n” consecutive identical FTP file transfers (get orput) initiated by a client virtual machine on the VM/ESA system. These filetransfers were to/from the client virtual machine′s 191 minidisk, which wasdefined in RAMAC 2 Array Subsystem storage. Minidisk cache was enabled forthis minidisk.


Migration: TCP/IP

Measurement Results: The measurement results are summarized in Table 10,Table 11, and Table 12.

Table 10. FTP Performance on a 9121-480: Get 2MB Files

Run IdDirectionModeTCP/IP Release

G2M_A243Get

ASCII2.4

G2M_A313Get

ASCII310

G2M_B243Get

Binary2.4

G2M_B313Get

Binary310

File Size (Kb)Files TransferredTotal KbElapsed Time (sec)Rate (Kb/sec)Rate Ratio

2073.85

1036942.0

246.91.000

2073.85

1036942.0

246.91.000

2073.85

1036942.1

246.31.000

2073.85

1036942.4

244.60.993

TCPIP CPU UsageCP CPU (sec)Virtual CPU (sec)Total CPU (sec)Total CPU RatioTotal CPU/Kb (msec)

1.482.524.00

1.0000.386

1.502.343.84

0.9600.370

1.512.544.05

1.0000.391

1.512.333.84

0.9480.370

VM Client CPU UsageCP CPU (sec)Virtual CPU (sec)Total CPU (sec)Total CPU RatioTotal CPU/Kb (msec)

0.5610.1910.751.0001.037

0.545.105.64

0.5250.544

0.530.851.38

1.0000.133

0.520.811.33

0.9640.128

Total CPU UsageTotal CPU (sec)Total CPU RatioTotal CPU/Kb (msec)

14.751.0001.423

9.480.6430.914

5.431.0000.524

5.170.9520.499

Table 11. FTP Performance on a 9121-480: Get 24KB Files


G24KA241Get

ASCII2.4

G24KA311Get

ASCII310

G24KB243Get

Binary2.4

G24KB313Get

Binary310


24.3100

243019.2

126.61.000

24.3100

243019.5

124.60.985

24.3100

243015.4

157.81.000

24.3100

243014.7

165.31.048


0.951.442.39

1.0000.984

0.961.382.34

0.9790.963

0.941.412.35

1.0000.967

0.941.342.28

0.9700.938


0.922.933.85

1.0001.584

0.902.843.74

0.9711.539

0.871.972.84

1.0001.169

0.881.882.76

0.9721.136


6.241.0002.568

6.080.9742.502

5.191.0002.136

5.040.9712.074


Migration: TCP/IP

The CPU usage data were obtained from the CP QUERY TIME command. Theelapsed times were obtained by summing the elapsed times reported for eachfile transfer by FTP′s console messages.

Measurement Discussion: There was no significant change in file transfer rate.On average, total CPU usage in the TCPIP virtual machine decreased by 3.7%.This is the same degree of improvement that was observed for the Telnetmeasurements described in “Telnet” on page 33 and arises from the pathlengthimprovements that were made to the TCP/IP stack in this release.

Total CPU usage in the client virtual machine decreased by 47% for the GET2MB ASCII case. The specific reason for this large improvement has not beenidentified. Client total CPU usage decreased by an average of 2.7% for theremaining cases.

Table 12. FTP Performance on a 9121-480: Put 2MB and 24KB Binary Files


P2M_B243Put

Binary2.4

P2M_B313Put

Binary310

P24KB243Put

Binary2.4

P24KB313Put

Binary310


2073.85

1036929.6

350.31.000

2073.85

1036929.6

350.31.000

24.3100

24308.1

300.01.000

24.3100

24308.2

296.30.988


2.063.125.18

1.0000.500

2.102.955.05

0.9750.487

1.141.672.81

1.0001.156

1.131.542.67

0.9501.099


0.480.851.33

1.0000.128

0.480.841.32

0.9920.127

0.771.902.67

1.0001.099

0.781.792.57

0.9631.058


6.511.0000.628

6.370.9780.614

5.481.0002.255

5.240.9562.156


Migration from Other VM Releases


The performance results provided in this report apply to migration from VM/ESA2.2.0. This section discusses how to use the information in this report along withsimilar information from earlier reports to get an understanding of theperformance of migrating from earlier VM releases.

Note: In this section, VM/ESA releases prior to VM/ESA 2.1.0 are referred towithout the version number. For example, VM/ESA 2.2 refers to VM/ESA Version1 Release 2.2.

Migration Performance Measurements MatrixThe matrix on the following page is provided as an index to all the performancemeasurements pertaining to VM migration that are available in the VM/ESAperformance reports. The numbers that appear in the matrix indicate whichreport includes migration results for that case:

10 VM/ESA Release 1.0 Performance Report





210 VM/ESA Version 2 Release 1.0 Performance Report

220 VM/ESA Version 2 Release 2.0 Performance Report

230 VM/ESA Version 2 Release 3.0 Performance Report (thisdocument)

See “Referenced Publications” on page viii for more information on thesereports.

Most of the comparisons listed in the matrix are for two consecutive VMreleases. For migrations that skip one or more VM releases, you can get ageneral idea how the migration will affect performance by studying theapplicable results for those two or more comparisons that, in combination, spanthose VM releases. For example, to get a general understanding of howmigrating from VM/ESA 2.1.0 to VM/ESA 2.3.0 will tend to affect VSE guestperformance, look at the VM/ESA 2.1.0 to VM/ESA 2.2.0 comparisonmeasurements and the VM/ESA 2.2.0 to VM/ESA 2.3.0 comparisonmeasurements. In each case, use the measurements from the systemconfiguration that best approximates your VM system.

The comparisons listed for the CMS-intensive environment include bothminidisk-only and SFS measurements. Internal throughput rate ratio (ITRR)information for the minidisk-only CMS-intensive environment has been extractedfrom the CMS comparisons listed in the matrix and is summarized in “MigrationSummary: CMS-Intensive Environment” on page 41.



Table 13. Sources of VM migration performance measurement results

Source Target ProcessorReport Number

CMS OV/VMVSE

GuestMVS

Guest

VM/SP 5 VM/ESA 1.0 (370)VM/ESA 1.0 (370)VM/ESA 1.0 (370)VM/ESA 2.0VM/ESA 2.0

4381-139221-1709221-1209221-1709221-120

10

20

20

20202020

VM/SP 6 VM/ESA 1.0 (370) 4381-139370-809370-30

101010

VM/SP HPO5 VM/ESA 1.0 (ESA)VM/ESA 2.0VM/ESA 2.0

3090*-200J9121-4809121-320

102020

VM/ESA 1.0 (370) VM/ESA 1.5 (370)VM/ESA 1.1VM/ESA 2.0VM/ESA 2.0

9221-1209221-1709221-1709221-120

22112020

2020

VM/XA* 2.0 VM/ESA 1.0 (ESA) 3090-600J 10

VM/XA 2.1 VM/ESA 1.0 (ESA)VM/ESA 1.0 (ESA)VM/ESA 1.0 (ESA)VM/ESA 1.0 (ESA)VM/ESA 1.1VM/ESA 1.1

3090-600J3090-200J9021-7209121-3209021-7209121-320

1010

11

1111

11

10

VM/ESA 1.0 (ESA) VM/ESA 1.1 3090-600J9021-7209021-5809121-4809121-3209221-170

1111111111

11

11

11

VM/ESA 1.1 VM/ESA 2.0 9021-9009021-7209121-4809121-3209221-170

20

20

20

2020

20

20

VM/ESA 2.0 VM/ESA 2.1 9121-7429121-4809121-3209221-170

2121

21

2121

21

VM/ESA 2.1 VM/ESA 2.2 9121-7429121-4809121-3209221-170

2222

2222

VM/ESA 2.2 VM/ESA 2.1.0 9121-7429121-4809121-3209221-170

210210

210

210210

VM/ESA 2.1.0 VM/ESA 2.2.0 9121-7429672-R539121-4809121-320

220220220 220

220

VM/ESA 2.2.0 VM/ESA 2.3.0 9121-7429121-4809121-320

220220

220



Migration Summary: CMS-Intensive EnvironmentA large body of performance information for the CMS-intensive environment hasbeen collected over the last several releases of VM. This section summarizesthe internal throughput rate (ITR) data from those measurements to show, forCMS-intensive workloads, the approximate changes in processing capacity thatmay occur when migrating from one VM release to another. As such, thissection can serve as one source of migration planning information.

The performance relationships shown here are limited to the minidisk-onlyCMS-intensive environment. Other types of VM usage may show differentrelationships. Furthermore, any one measure such as ITR cannot provide acomplete picture of the performance differences between VM releases. The VMperformance reports can serve as a good source of additional performanceinformation.

Table 14 summarizes the approximate ITR relationships for the CMS-intensiveenvironment for migrations to VM/ESA 2.3.0.

Explanation of columns:

Case The set of conditions for which the stated ITRR approximately applies.When not specified, no large variations in ITRR were found among thecases that were measured.

ITRR VM/ESA 2.3.0 ITR divided by the source ITR. A number greater than 1.00indicates an improvement in processor capacity.

Notes Applicable notes (described below).

1. The VM/SP 5 system is assumed to include APAR VM30315, the performanceSPE that adds segment protection and 4KB key support. Othermeasurements have shown that VM/SP 5 ITR is 4% to 6% lower without thisAPAR.

Table 14. Approximate VM/ESA 2.3.0 relative capacity: CMS-intensive environment

Source Case ITRR Notes

VM/SP 5 9221-120 0.91 1,2,5-7

VM/SP 6 9221-120 1.06 2,5-7

VM/ESA 1.0 (370) 9221-1209221-170

0.991.06

2,5-74-7

VM/ESA 1.5 (370) 9221-1209221-170

0.971.04

2,5-74-7

VM/SP HPO 5 UPMP

1.001.11

4,6,73,4,6,7

VM/XA 2.0 1.23 7

VM/XA 2.1 1.20 7

VM/ESA 1.0 ESA 1.16 7

VM/ESA 1.1 1.11 7

VM/ESA 2 1.10 7

VM/ESA 2.1 1.09 7

VM/ESA 2.2 1.06 7

VM/ESA 2.1.0 1.01

VM/ESA 2.2.0 1.00

Migration from Other VM Releases 41


2. This includes an increase of central storage from 16MB to 32MB tocompensate for VM/ESA′s larger storage requirements. The VM/ESA casealso includes 16MB of expanded storage for minidisk caching.

3. The VM/SP HPO 5 to VM/ESA 1.0 (ESA Feature) portion of the derivation wasdone with a reduced think time to avoid a 16MB-line real storage constraintin the HPO case. In cases where the base HPO system is 16MB-lineconstrained, migration to VM/ESA will yield additional performance benefitsby eliminating this constraint.

4. VM/ESA 2.3.0 supports a larger real memory size than the stated migrationsource and this potential benefit is not reflected in the stated ITR ratios.Migrations from memory-constrained environments will yield additional ITRRand other performance benefits when the VM/ESA 2.3.0 system hasadditional real storage.

For example, the stated VM/SP HPO 5 to VM/ESA 2.3.0 ITRR foruniprocessors is based (in part) on a VM/SP HPO 5 to VM/ESA 2 comparison,which showed an ITRR of 0.91. Those measurements were done on a9121-320 system with its 256MB of storage configured as 64MB of realstorage and 192MB of expanded storage (64MB/192MB). The 9121-320 had tobe configured that way because 64MB is the maximum real storagesupported by HPO. When VM/SP HPO Release 5.0 (64MB/192MB) wascompared to VM/ESA 2 (192MB/64MB), an ITRR of 0.95 was observed. See“CMS-Intensive Migration from VM/SP HPO Release 5” in the VM/ESARelease 2 Performance Report for details.

5. These results apply to the case where the following recommended tuning isdone for the target system:

• Use minidisk caching.

• On VM/ESA systems before VM/ESA Release 2, set DSPSLICE to threetimes the default. Otherwise, use the default value.

• For the 9221-120, set the VTAM DELAY operand in the VTAM CTCAchannel-attachment major node to 0.3 seconds. For the 9221-170, set theVTAM delay to 0.2 seconds.

• Set IPOLL ON for VTAM.

• Preload the key shared segments.

See section “CMS-Intensive Migration from VM/ESA 1.1,” subsection“9221-170 / Minidisk” in the VM/ESA Release 2 Performance Report for moreinformation on these tuning items. The purpose of this tuning is to configureVM/ESA for use on ESA-mode 9221 processors. If this tuning is not done,lower ITR ratios will be experienced. For example, for the FS7B0RCMS-intensive workload, going from VM/ESA 1.0 (370 Feature) to VM/ESA 1.1resulted in an ITRR of 0.95 with the above tuning and an ITRR of 0.86 withoutit. This comparison is shown in the VM/ESA Release 1.1 PerformanceReport.

6. There has been growth in CMS real storage requirements on a per userbasis. This growth is reflected in the ITR ratios to only a limited extent andshould therefore be taken into consideration separately. The most significantgrowth took place in VM/SP 6 and in VM/ESA 2.0. The VM/SP 6 increase canaffect the performance of migrations from VM/SP 5 and VM/SP HPO 5. TheVM/ESA 2.0 growth can affect the performance of migrations from VMreleases prior to VM/ESA 2.0. Storage constrained environments with largenumbers of CMS users will be the most affected.



7. This ITRR value depends strongly upon the fact that CMS is now shippedwith most of its REXX execs and XEDIT macros compiled (see “PerformanceImprovements” on page 3). If these are already compiled on your system,divide the ITRR shown by 1.07.

Table 14 on page 41 only shows performance in terms of ITR ratios (processorcapacity). It does not provide, for example, any response time information. Animproved ITR tends to result in better response times and vice versa. However,exceptions occur. An especially noteworthy exception is the migration from370-based VM releases to VM/ESA. In such migrations, response times havefrequently been observed to improve significantly, even in the face of an ITRdecrease. One pair of measurements, for example, showed a 30% improvementin response time, even though ITR decreased by 5%. When this occurs, factorssuch as XA I/O architecture and minidisk caching outweigh the adverse effects ofincreased processor usage. These factors have a positive effect on responsetime because they reduce I/O wait time, which is often the largest component ofsystem response time.

Keep in mind that in an actual migration to a new VM release, other factors(such as hardware, licensed product release levels, and workload) are oftenchanged in the same time frame. It is not unusual for the performance effectsfrom upgrading VM to be outweighed by the performance effects from theseadditional changes.

These VM ITRR estimates can be used in conjunction with the appropriatehardware ITRR figures to estimate the overall performance change that wouldresult from migrating both hardware and VM. For example, suppose that thenew processor ′s ITR is 1.30 times that of the current system and suppose thatthe migration also includes an upgrade from VM/ESA 2.1 to VM/ESA 2.3.0. FromTable 14 on page 41, the estimated ITRR for migrating from VM/ESA 2.1 toVM/ESA 2.3.0 is 1.09. Therefore, the estimated overall increase in systemcapacity is 1.30*1.09 = 1.42.

Table 14 represents CMS-intensive performance for the case where all files areon minidisks. The release-to-release ITR ratios for shared file system (SFS)usage are very similar to the ones shown here.

Migration from Other VM Releases 43

Record Level Minidisk Caching

New Functions

A number of the functional enhancements in VM/ESA 2.3.0 have performanceimplications. This section contains performance evaluation results for thefollowing functions:

• Record Level Minidisk Caching

• fork()

• MQSeries Client Support

Record Level Minidisk CachingThis section provides measurement results that compare the performance ofrecord level minidisk caching to the (default) track-based minidisk caching.Results are shown for a random access workload, a sequential access workload,and the FS8F0R CMS-intensive workload.

See “Performance Improvements” on page 3 for a description of record levelminidisk caching.

Random / Sequential ResultsA CMS program was written to do I/Os to a very large minidisk file (about 9003390 cylinders). The program could be run in either random or sequential mode.When run in random mode, it simulated the mostly-random I/O pattern of acustomer database environment. When run in sequential mode, it read the filesequentially.

These two workloads were run on a dedicated 9121-480 configured with 128MB ofcentral storage and 128MB of expanded storage. The real storage minidiskcache and the expanded storage minidisk cache were both fixed at 2MB. Theelapsed time results are summarized in Table 15.

These results illustrate that record level caching can result in substantialperformance improvements for workloads characterized by random access oflarge files. However, more sequential workloads or those with a greater localityof reference will tend to do worse with record level minidisk cache.

Table 15. Record level MDC performance with random and sequential workloads

File Access Track Record Ratio

RandomSequential

1353294

883587

0.652.00

Note: Elapsed time in seconds.



CMS-Intensive ResultsWorkload: FS8F0R





DASD:


Communications:



Virtual Machines:

Measurement Discussion: Table 16 on page 46 shows a comparison of recordlevel minidisk cache to full track minidisk cache for the FS8F0R CMS-intensiveworkload run on the 9121-480 processor. These results show that overallperformance was similar for this workload. With record level caching, externalresponse time (AVG LAST(T)) improved by 10% while processor capacity(ITR(H)) decreased by 0.8%.

DASD I/Os (NONPAGE RIO/CMD(V)) increased and MDC HIT RATIO decreaseddue to the frequent appearance of multiple cache misses per track. However,average DASD access time (DASD RESP TIME(V)) and minidisk cache size (MDC

Type ofDASD

ControlUnit



3390-3 RAMAC 2 4 8 163390-2 3990-2 4 16 63390-2 3990-3 2 2 R3390-2 3990-3 4 2


Control Unit Speed

3088-08 1 NA 4.5MB



SMART 1 RTM 32MB/XA 3 % 400 QUICKDSP ONVTAMXA 1 VTAM/VSCS 64MB/XA 10000 560 QUICKDSP ONWRITER 1 CP monitor 2MB/XA 100 QUICKDSP ONUnnnn 2040 Users 3MB/XC 100

New Functions 45


REAL SIZE (MB)) decreased because unneeded DASD records were not beingread into the cache.

The decrease in processor capacity was primarily due to a 1.5% increase in CPCPU usage (CP/CMD(H)), reflecting the fact that record level MDC is somewhatless efficient than full track caching for typical CMS workloads.

The FS8F0R workload generates an I/O access pattern that is intermediatebetween the random and sequential workloads described earlier.

Table 16 (Page 1 of 3). Record level minidisk cache: FS8F0R CMS-intensiveworkload on the 9121-480

Minidisk CacheReleaseRun ID

Track2.3.0

L2AE2043

Record2.3.0



256MB0MB2040

102

256MB0MB2040

102


0.1310.4680.3500.3200.2980.424

0.1350.4510.3430.3070.2650.382

0.004-0.017-0.007-0.013-0.032-0.042

3.05%-3.63%-2.00%-4.06%

-10.76%-9.80%


26.1565.1971.310.91478.9536.0953.911.0001.000

26.1763.9071.400.89578.3635.0952.610.9920.972

0.02-1.290.09

-0.019-0.59-1.01-1.30

-0.008-0.028

0.10%-1.98%0.12%

-2.10%-0.75%-2.80%-2.41%-0.75%-2.80%


25.33125.381

8.9648.413

16.36716.967

25.52325.490

9.0948.403

16.42917.086

0.1920.1090.130

-0.0100.0620.119

0.76%0.43%1.45%

-0.12%0.38%0.70%


180.65181.00

90.3390.50

116.72121.00

90.0490.0051.5754.00

1.551.50

182.24182.00

91.1291.00

117.31122.00

90.8591.0051.9654.00

1.551.49

1.591.000.800.500.591.000.811.000.390.000.010.00

0.88%0.55%0.88%0.55%0.50%0.83%0.90%1.11%0.76%0.00%0.38%

-0.27%





Track2.3.0

L2AE2043

Record2.3.0



256MB0MB2040

102

256MB0MB2040

102


2452KB350KB

8354125

26.5173

62520.94

1490

2452KB350KB

8354148

26.5176

62460.94

1460

0KB0KB

023

0.03

-60.00-30

0.00%0.00%0.00%0.04%0.04%1.73%

-0.10%0.10%

-2.01%


716474

16.687200.500

2.81100

0.0008.862

717471

16.638198.700

2.78300

0.0008.865

1-3

-0.048-1.800-0.029

00

0.0000.003

0.14%-0.63%-0.29%-0.90%-1.02%

nanana

0.04%


46.590.00

44.200.00

-2.390.00

-5.13%na


7039.858

3945.5252.713

18.70040.7

0.0207

9.70195

0.94

7109.944

4436.2043.421

16.00017.1

0.0204

9.33173

0.83

70.086

490.6800.708

-2.700-23.6

0.0-3

-0.37-22

-0.11

1.00%0.87%

12.44%12.30%26.10%

-14.44%-58.01%

na-1.45%-3.81%

-11.28%-11.70%


13.86726.058

2.2580.7350.1920.0251.2491.0163.6072.659

11.9970.941

53.62234.31849.485

13.92826.132

2.2560.7350.1930.0241.2501.0813.6102.682

11.9820.941

54.43834.29651.567

0.0610.074

-0.0030.0000.0010.0000.0010.0650.0030.023

-0.0150.0010.817

-0.0222.082

0.44%0.28%

-0.13%-0.05%0.44%

-0.38%0.11%6.38%0.07%0.87%

-0.12%0.07%1.52%

-0.06%4.21%

New Functions 47

fork()



Track2.3.0

L2AE2043

Record2.3.0



256MB0MB2040

102

256MB0MB2040

102


5673.94961.48012.4695

1.017

5583.99151.50172.4898

1.081

-90.04190.02160.0203

0.065

-1.59%1.06%1.46%0.82%6.35%


fork()This section contains measurement results that evaluate the performance of thefork() support that has been added to OpenEdition for VM/ESA in VM/ESA 2.3.0.

The VM/ESA support is a partial implementation of the fork() function. Mostnotably, the VM implementation does not create a separate address space forthe child process. Because of this and other functional differences, fork() onVM/ESA comes with certain restrictions. For example, fork() must be followed byone of the exec functions (execl(), execle(), etc) in the child process. For furtherinformation on fork() and the VM/ESA restrictions, see C for VM/ESA LibraryReference.

A C program was written that executes a loop consisting of fork(), execl() by thechild process to another C program that does an immediate return, and wait() bythe parent for child process termination. This program was measured with onesuch loop iteration and with 101 loop iterations. The 1-iteration results weresubtracted from the 101-iteration results and then divided by 100 in order toobtain per-iteration performance figures. Elapsed time and CPU usage data forboth the user virtual machine and the Byte File System (BFS) server virtualmachine were collected using the CP QUERY TIME command. BFS serverstatistics were collected using the QUERY FILEPOOL COUNTER command. Allthis information was collected immediately prior to and immediately followingexecution of the C program.

The fraction of all user virtual machine CPU usage due to fork() and wait() wasestimated by analysis of instruction trace data. The remaining virtual machineCPU usage and all of the BFS server activity resulted from execl(), including theloading and execution of the null C program.

The measurements were made on a non-dedicated 2003-156 during low usageconditions when contention from other system activity was minimal. The BFSserver was dedicated during the measurement. Multiple measurement runswere obtained to verify repeatability. The results, shown in Table 17, are from atypical measurement run.


MQSeries Client Support

The CPU results have been renormalized to a 9021-900 so that they can bedirectly compared to the results obtained for other OpenEdition for VM/ESAfunctions published in the VM/ESA Version 2 Release 1.0 Performance Report.

As shown in the table, most of the measured CPU usage is from execl(). Thelow fork() CPU usage reflects the fact that VM/ESA′s fork() implementation doesnot create the child process in a new address space.

Table 17. Performance of individual OpenEdition for VM/ESA calls on a 9021-900processor

Function

ElapsedTime

(msec)

TotalCPU Time

(msec)

UserCPU TIme

(msec)

ServerCPU Time

(msec)BFS

CallsBFSI/Os

fork() + wai t ( )execl()

2.3123.0

2.335.8

2.330.9

04.9

03

03

MQSeries Client SupportThe Message Queueing Interface is a popular means of enabling applications ondifferent computing systems/architectures to work together. This interface isnow available to VM applications through use of the MQSeries* client supportprovided by VM/ESA 2.3.0. This support, linked with the VM application, enablesmessages to be added to and removed from queues managed by an MQSeriesqueue manager residing on another platform elsewhere in the network. Thissection summarizes the results of performance measurements that wereobtained to evaluate the performance of this support.

Measurement Method: For VM/ESA, the MQ* API is available to applicationswritten in C, COBOL, PL/I, assembler, and REXX. Measurements were obtainedfor the C and REXX cases. The measured workloads were based on the sampleapplications provided on the 193 CMS minidisk. These write a given number ofmessages to a specified queue using an MQPUT loop and then read them allback using an MQGET loop. For the C measurements, AMQSPUT0 was modifiedto read the messages to be put on the queue from a CMS file. For the REXXmeasurements, the RXMQVPUT and RXMQVGET samples were modified tocomment out all console messages that are produced during execution of theMQGET and MQPUT loops. The RXMQV module was NUCXLOADed before doingthe REXX measurements, as recommended by VM documentation.

The client workload was run on a VM/ESA 2.3.0 production system on a 2003-156processor. The measurements were obtained during a period of low systemusage so as to minimize the effects of contention from other concurrent activity.The target queue was managed by an MQ server that was running on an AIXRS/6000 system in a remote location. TCP/IP was used for communications.

Measurements were made for the case of 1 message and for 500 messages.Separate data were collected for the put and get operations. Elapsed time andCPU usage by the virtual machine running the tests were obtained using the CPQUERY TIME command. The 1 message results were subtracted from the 500message results to factor out initialization and termination and the differenceswere divided by 499 to express the results on a per-message basis. The resultsfor a typical set of measurements are summarized in Table 18. Repeatmeasurements gave similar results.

New Functions 49

MQSeries Client Support

Measurement Results

The CPU usage shown in Table 18 is for the virtual machine running the MQapplication. It includes CPU usage within the virtual machine itself and CPUusage for CP services used by that virtual machine (TOTCPU). There isadditional CPU usage in the TCPIP virtual machine resulting from TCP/IPcommunications activity. INDICATE USER measurements of the TCPIP virtualmachine indicate that there is approximately 2 msec of TCPIP CPU usage perMQ message.

The COBOL, PL/I, and assembler cases, not measured, should haveperformance characteristics that are similar to the C results shown here. TheREXX case has substantially higher CPU requirements. This is due to the morecomplex interface that is needed to communicate between the REXX programand the RXMQV module that contains the actual MQ client code.

Elapsed time per message is heavily determined by the performancecharacteristics of the network connecting the client and server systems.Because of this, elapsed times for other network configurations can varysubstantially from these results.

For more information on the sample applications, see Appendix C of the “CMSApplication Development Guide.” For more information about MQSeries, see the“MQSeries: Application Programming Guide” and the other MQSeriespublications.

Table 18. VM MQSeries performance on a 2003-156

Language FunctionElapsed Timeper msg (ms)

CPU Timeper msg (ms)

C getput

6567

1.00.9

REXX getput

99103

13.014.1


Migration from VTAM to Telnet

Additional Evaluations

This portion of the report includes results from a number of additional VM/ESA(including TCP/IP) performance measurement evaluations that have beenconducted during the past year.

Migration from VTAM to TelnetThe section explores the performance implications of migrating end-user 3270connectivity from VTAM to TCP/IP Telnet.

Measurements were obtained by running the FS8F0R workload on a 9121-480processor with the end users simulated by TPNS running on a separate system.VM/ESA 2.2.0 was used for all measurements. For the base measurement,connectivity was provided by VTAM 3.4.1 through a CTCA connection with theTPNS system. This measurement configuration is equivalent to that used for theCMS-intensive measurements shown in “9121-480 / Minidisk” on page 17.

Table 19 compares this VTAM base measurement to a correspondingmeasurement using TCP/IP 2.4 Telnet through a CTCA connection, whileTable 20 compares the VTAM base measurement to a corresponding TCP/IP 2.4measurement with connectivity to the TPNS system provided through a 3172-3Interconnect Controller and a 16Mbit IBM Token Ring. For each measurement,the number of simulated users was chosen such that the measured 9121-480system was running at approximately 90% processor utilization.



Workload: FS8F0R





DASD:


Communications (CTCA):

Communications (Token Ring):




Virtual Machines:

Type ofDASD

ControlUnit



3390-3 RAMAC 2 4 8 163390-2 3990-2 4 16 63390-2 3990-3 2 2 R3390-2 3990-3 4 2


Control Unit Speed

3088-08 1 NA 4.5MB



VTAMXA or 1 VTAM/VSCS 64MB/XA 10000 560 QUICKDSP ONTCPIP 1 TCP/IP 256MB/XA 10000 2700 QUICKDSP ON

SMART 1 RTM 32MB/XA 3 % 400 QUICKDSP ONWRITER 1 CP monitor 2MB/XA 100 QUICKDSP ONUnnnn 2000/1800 Users 3MB/XC 100



Measurement Discussion: The Table 19 comparison is more equivalent becausethe method of physical interconnection is held constant. The Table 20comparison shows TCP/IP Telnet performance for the more typical LAN-basedinterconnection.

Looking at the Table 19 comparison, we see that external response time (AVGLAST(T)) decreased by 4%, while the internal throughput rate (ITR(H)) decreasedby 10%. The ITR drop reflects the fact that TCP/IP CPU usage is somewhathigher than VTAM ′s for this type of function. Roughly half of this increase showsup as processing time that is charged to the TCPIP virtual machine, whichincludes both the TCP/IP protocol stack and internal Telnet client code. Theremaining increase shows up in CP CPU usage that is charged to the end usersas the result of Diagnose Code X′7C′ processing, which operates on behalf ofboth the TCPIP virtual machine and the user virtual machines for which it isproviding logical device support.

VTAM supports the 3270 interface through the *CCS CP system service(accessed using IUCV requests), while Telnet provides this function through useof the Diagnose X′7C′ logical device support facility. This difference is reflectedin the results as a large decrease in PRIVOP/CMD and much of the largeincrease in DIAG/CMD. The fact that diagnose X′7C′ has a longer pathlengththan *CCS accounts for much of the CPU usage increase observed in the TCP/IPmeasurement relative to the VTAM base measurement. Another contributingfactor is that TCP/IP does more communication I/Os than VTAM, as shown by theincrease in DIAG 98/CMD(V).

The TCPIP virtual machine uses more real storage than does the VTAM virtualmachine (see WKSET(V)). More pages had to be reserved in the TCPIP case(2700 as opposed to 560 for VTAM) in order to eliminate paging from thecommunications server. The “trimmed” buffer pool configuration defined inTable 21 on page 59 was used for the TCP/IP measurements. As discussed in“Reduced TCP/IP Real Storage Requirements” on page 58, it was necessary forthese TCP/IP 2.4 measurements to avoid defining an excessive number of TCP/IPbuffers but this tuning is no longer necessary when using TCP/IP 310.

For the most part, the above discussion also applies to the LAN-based Table 20comparison. The main differences are that TCP/IP response times are betterand the amount of CPU usage increase relative to the VTAM base measurementis somewhat smaller when the VTAM base measurement is compared to TCP/IPTelnet with token ring interconnection.

Until recently, the number of Telnet users on a given VM/ESA system waslimited to 4096 — the maximum number of logical devices supported by CP. WithVM/ESA 2.3.0, this limit has been raised to 32,768.

The observations shown here should also apply to larger systems with largernumbers of users. However, CPU usage in the TCPIP virtual machine canbecome a bottleneck on large systems. If we start with the 27.9% TCPIP CPUutilization observed for run L29E1801, a simple linear projection indicates that asystem with a per-engine processor capacity similar to the 9121-480 wouldbottleneck on TCPIP CPU usage at or below 1800*(100/28) = 6400 users. Muchof VTAM′s processor usage can be offloaded to one or more VSCS virtualmachines but TCP/IP VM does not have a corresponding capability.

Additional Evaluations 53


Table 19 (Page 1 of 2). VTAM to Telnet Migration on a 9121-480: CTCA

CommunicationsInterconnectionRun ID

VTAM 3.4.1CTCA

L29E2006

TCP/IP 2.4CTCA

L29E1800Difference %Difference


256MB0MB2000

102

256MB0MB1800

nana

2

-200 -10.00%


0.1270.4410.3310.3010.2740.390

0.1140.8610.2460.2250.2930.404

-0.0130.420

-0.085-0.0760.0200.015

-10.24%95.24%

-25.68%-25.14%

7.13%3.72%


26.1763.6570.000.90979.4136.1453.891.0001.000

24.5157.7263.020.91671.1132.5953.270.8950.902

-1.66-5.93-6.980.007-8.30-3.55-0.62

-0.105-0.098

-6.33%-9.32%-9.97%0.73%

-10.46%-9.82%-1.15%

-10.46%-9.82%


25.18625.143

8.8918.286

16.29516.857

28.12728.08611.57910.94916.54817.138

2.9412.9442.6882.6630.2530.280

11.68%11.71%30.24%32.14%

1.55%1.66%


176.30176.00

88.1588.00

114.06118.00

87.6888.0050.0852.00

1.551.49

177.25177.00

88.6388.50

104.28108.00

89.2689.0043.0845.00

1.701.64

0.951.000.480.50

-9.78-10.00

1.581.00

-7.00-7.000.150.15

0.54%0.57%0.54%0.57%

-8.58%-8.47%1.81%1.14%

-13.98%-13.46%

9.97%9.88%


2804KB350KB

8254314

27.2172

59640.94

1465

2804KB350KB

8455503

30.8177

52060.98946

0KB0KB

21189

3.75

-7580.04-519

0.00%0.00%2.44%2.19%

13.54%2.91%

-12.71%4.15%

-35.43%



Table 19 (Page 2 of 2). VTAM to Telnet Migration on a 9121-480: CTCA


VTAM 3.4.1CTCA

L29E2006

TCP/IP 2.4CTCA



256MB0MB2000

102

256MB0MB1800

nana

2

-200 -10.00%


697458

16.500191.400

2.73400

0.0008.757

660408

16.947170.300

2.70200

0.0008.759

-37-50

0.447-21.100

-0.03200

0.0000.002

-5.31%-10.92%

2.71%-11.02%

-1.17%nanana

0.02%


46.040.00

23.490.00

-22.550.00

-48.97%na


6929.886

3885.5432.809

19.80041.0

0.0199

9.51188

0.94

87513.885

6089.6486.945

19.70042.6

0.0179

8.69168

0.94

1833.999

2204.1054.137

-0.1001.60.0-20

-0.82-20

0.00

26.45%40.45%56.70%74.06%

147.29%-0.51%3.88%

na-10.05%

-8.62%-10.64%

0.00%

PRIVOPsPRIVOP/CMDDIAG/CMDDIAG 04/CMDDIAG 08/CMDDIAG 0C/CMDDIAG 14/CMDDIAG 58/CMDDIAG 7C/CMDDIAG 98/CMDDIAG A4/CMDDIAG A8/CMDDIAG 214/CMDDIAG 270/CMDSIE/CMDSIE INTCPT/CMDFREE TOTL/CMD

13.94226.668

2.3730.7350.2120.0251.2510.0001.0823.5602.672

12.4600.920

52.92934.40449.629

1.60336.640

2.5820.7330.2120.0241.2515.7835.1023.5462.662

12.4440.918

64.42444.45353.682

-12.3399.9720.209

-0.0030.0000.0000.0015.7834.020

-0.013-0.011-0.017-0.00211.49610.049

4.053

-88.50%37.39%

8.80%-0.37%0.02%

-1.24%0.06%

na371.47%

-0.38%-0.40%-0.13%-0.25%21.72%29.21%

8.17%

VTAM or TCPIP MachineWKSET (V)CPU UTIL (V)TOT CPU/CMD (V)CP CPU/CMD (V)VIRT CPU/CMD (V)DIAG 98/CMD (V)

54727.7

3.95241.47622.4762

1.082

270033.1

5.23602.36402.8720

5.102

21535.4

1.28360.88780.3958

4.020

393.60%19.49%32.48%60.14%15.98%

371.62%




Table 20 (Page 1 of 2). VTAM/CTCA to Telnet/Token Ring Migration on a 9121-480


VTAM 3.4.1CTCA

L29E2006

TCP/IP 2.43172-3/TRL29E1801

Difference %Difference


256MB0MB2000

102

256MB0MB1800

nana

2

-200 -10.00%


0.1270.4410.3310.3010.2740.390

0.0930.8040.2210.1980.2050.306

-0.0340.363

-0.110-0.103-0.068-0.084

-26.77%82.31%

-33.23%-34.15%-24.86%-21.44%


26.1763.6570.000.90979.4136.1453.891.0001.000

24.4856.5963.100.89773.4032.9453.500.9240.912

-1.68-7.06-6.90

-0.012-6.01-3.19-0.39

-0.076-0.088

-6.42%-11.09%

-9.86%-1.37%-7.56%-8.83%-0.73%-7.56%-8.83%


25.18625.143

8.8918.286

16.29516.857

27.24627.25811.08310.45916.16316.799

2.0612.1152.1922.174

-0.131-0.059

8.18%8.41%

24.66%26.23%-0.81%-0.35%


176.30176.00

88.1588.00

114.06118.00

87.6888.0050.0852.00

1.551.49

171.93172.00

85.9686.00

101.99106.00

86.7187.0041.6143.00

1.691.62

-4.37-4.00-2.19-2.00

-12.07-12.00

-0.96-1.00-8.47-9.000.140.13

-2.48%-2.27%-2.48%-2.27%

-10.58%-10.17%

-1.10%-1.14%

-16.92%-17.31%

9.06%8.79%


2804KB350KB

8254314

27.2172

59640.94

1465

2804KB350KB

8655481

30.8177

52290.98897

0KB0KB

41167

3.75

-7350.03-568

0.00%0.00%4.88%2.15%

13.50%2.91%

-12.32%3.69%

-38.77%



Table 20 (Page 2 of 2). VTAM/CTCA to Telnet/Token Ring Migration on a 9121-480


VTAM 3.4.1CTCA

L29E2006

TCP/IP 2.43172-3/TRL29E1801



256MB0MB2000

102

256MB0MB1800

nana

2

-200 -10.00%


697458

16.500191.400

2.73400

0.0008.757

663408

16.973169.100

2.68000

0.0008.780

-34-50

0.473-22.300

-0.05400

0.0000.022

-4.88%-10.92%

2.87%-11.65%

-1.99%nanana

0.26%


46.040.00

22.070.00

-23.970.00

-52.06%na


6929.886

3885.5432.809

19.80041.0

0.0199

9.51188

0.94

74011.727

4707.4484.769

19.80042.5

0.0180

8.69170

0.94

481.842

821.9061.9600.000

1.40.0-19

-0.82-18

0.00

6.94%18.63%21.13%34.38%69.79%

0.00%3.52%

na-9.55%-8.62%-9.57%0.00%

PRIVOPsPRIVOP/CMDDIAG/CMDDIAG 04/CMDDIAG 08/CMDDIAG 0C/CMDDIAG 14/CMDDIAG 58/CMDDIAG 7C/CMDDIAG 98/CMDDIAG A4/CMDDIAG A8/CMDDIAG 214/CMDDIAG 270/CMDSIE/CMDSIE INTCPT/CMDFREE TOTL/CMD

13.94226.668

2.3730.7350.2120.0251.2510.0001.0823.5602.672

12.4600.920

52.92934.40449.629

1.58634.642

2.5760.7370.2120.0251.2505.8802.9163.5662.680

12.5020.920

56.98838.75251.568

-12.3567.9730.2030.0010.0010.000

-0.0015.8801.8340.0070.0080.042

-0.0014.0604.3481.940

-88.62%29.90%

8.54%0.20%0.33%0.03%

-0.05%na

169.46%0.18%0.29%0.33%

-0.08%7.67%

12.64%3.91%

VTAM or TCPIP MachineWKSET (V)CPU UTIL (V)TOT CPU/CMD (V)CP CPU/CMD (V)VIRT CPU/CMD (V)DIAG 98/CMD (V)

54727.7

3.95241.47622.4762

1.082

270027.9

4.42901.99902.4300

2.916

21530.2

0.47660.5228

-0.04621.834

393.60%0.72%

12.06%35.42%-1.87%

169.55%



Reduced TCP/IP Real Storage Requirements

Reduced TCP/IP Real Storage RequirementsThe page reference locality within the TCPIP virtual machine has beensignificantly improved with TCP/IP 310, especially for Telnet. In prior releases,excess buffers were periodically referenced even though they were neveractually used. This tended to result in page faults in the TCPIP virtual machine,degrading performance. TCP/IP 310 fixes this problem. In addition, certainbuffers and control blocks have been reorganized in order to occupy lessstorage. As a result, performance is no longer adversely affected by thepresence of unused TCP/IP buffers. This is shown by the performance resultsprovided in this section.

Workload: FS8F0R





DASD:


Communications:


Type ofDASD

ControlUnit



3390-3 RAMAC 2 4 8 163390-2 3990-2 4 16 63390-2 3990-3 2 2 R3390-2 3990-3 4 2





Virtual Machines:

Two different TCP/IP buffer pool configurations were used (see Table 21). The“trimmed” case was determined by setting the size of each buffer pool to beabout 10% larger than the high water mark requirements shown by the NETSTATPOOLSIZE command while running the Telnet workload.

Measurement Discussion: Preliminary TCP/IP 2.4 measurements using theexcess buffer pool configuration yielded results that showed severe performancedegradation due to high amounts of paging in the TCPIP virtual machine eventhough 2700 pages were reserved. In one example measurement, averageresponse time was 4.6 seconds and the TCPIP virtual machine was sustaining 52page reads per second. This problem went away when the trimmed buffer poolconfiguration was used. The TCPIP virtual machine then ran with zero pagingwhen 2700 pages were reserved for it (see the first measurement in Table 22).

In TCP/IP 310, several aspects of TCPIP buffer pool management were changedin order to solve this page reference problem. In order to verify theeffectiveness of these changes, the TCP/IP 2.4 measurement with the trimmedbuffer pool configuration was rerun using TCP/IP 310 and the original excessbuffer pool configuration (the second measurement in Table 22). The twomeasurements are equivalent within run variability.



TCPIP 1 TCP/IP 256MB/XA 10000 2700 QUICKDSP ONSMART 1 RTM 32MB/XA 3 % 400 QUICKDSP ONWRITER 1 CP monitor 2MB/XA 100 QUICKDSP ONUnnnn 1800 Users 3MB/XC 100

Table 21. Measured buffer pool settings

TCP/IP buffer pool Excess Trimmed

ACBPoolSizeAddressTranslationPoolSizeCCBPoolSizeDataBufferPoolSizeEnvelopePoolSizeIPRoutePoolSizeLargeEnvelopePoolSizeRCBPoolSizeSCBPoolSizeSKCBPoolSizeSmallDataBufferPoolSizeTCBPoolSizeTinyDataBufferPoolSizeUCBPoolSize

10000150050015000 81925000300500105000500015000 204810000500010

100015020150 8192300100101020102500 204820002010



Table 22 (Page 1 of 2). Telnet results showing improved TCP/IP buffer management

TCP/IP ReleaseTCP/IP BuffersRun ID

2.4TrimmedL29E1800

310Excess


EnvironmentReal StorageExp. StorageUsersProcessors

256MB0MB1800

2

256MB0MB1800

2


0.1140.8610.2460.2250.2930.404

0.1090.8590.2390.2200.2960.404

-0.005-0.002-0.007-0.0050.0030.000

-4.39%-0.23%-2.85%-2.20%1.02%0.12%


24.5157.7263.020.91671.1132.5953.271.0001.000

24.4957.9762.880.92270.7932.6753.300.9961.003

-0.020.25

-0.140.006-0.310.080.03

-0.0040.003

-0.08%0.43%

-0.23%0.66%

-0.44%0.25%0.05%

-0.44%0.25%


28.12728.08611.57910.94916.54817.138

28.25128.31011.58710.97416.66317.336

0.1240.2240.0080.0250.1160.198

0.44%0.80%0.07%0.23%0.70%1.16%


177.25177.00

88.6388.50

104.28108.00

89.2689.0043.0845.00

1.701.64

177.63178.00

88.8189.00

104.77109.00

89.4889.0043.4245.00

1.701.63

0.371.000.190.500.491.000.220.000.340.000.00

-0.01

0.21%0.56%0.21%0.56%0.47%0.93%0.24%0.00%0.78%0.00%

-0.26%-0.36%


2804KB350KB

8455503

30.8177

52060.98946

2804KB350KB

8555513

30.8195

51960.99927

0KB0KB

110

0.018

-100.00-19

0.00%0.00%1.19%0.02%0.02%

10.17%-0.19%0.19%

-2.01%



Table 22 (Page 2 of 2). Telnet results showing improved TCP/IP buffer management

TCP/IP ReleaseTCP/IP BuffersRun ID

2.4TrimmedL29E1800

310Excess


EnvironmentReal StorageExp. StorageUsersProcessors

256MB0MB1800

2

256MB0MB1800

2


660408

16.947170.300

2.70200

0.0008.759

655407

16.891167.900

2.67000

0.0008.795

-5-1

-0.056-2.400-0.032

00

0.0000.036

-0.76%-0.25%-0.33%-1.41%-1.18%

nanana

0.41%


23.490.00

24.210.00

0.720.00

3.06%na


87513.885

6089.6486.945

19.70042.6

0.0179

8.69168

0.94

87513.916

6059.6226.952

19.60043.0

0.0179

8.63169

0.94

00.032

-3-0.0260.006

-0.1000.40.0

0-0.06

10.00

0.00%0.23%

-0.49%-0.26%0.09%

-0.51%0.94%

na0.00%

-0.69%0.60%0.00%


1.60336.640

2.5820.7330.2120.0241.2515.1023.5462.662

12.4440.918

64.42444.45353.682

1.61136.694

2.5850.7340.2120.0241.2505.1173.5622.673

12.4590.920

64.54143.88853.630

0.0070.0540.0030.0010.0000.000

-0.0010.0150.0160.0110.0150.0010.116

-0.565-0.052

0.46%0.15%0.12%0.16%

-0.02%0.59%

-0.10%0.29%0.44%0.42%0.12%0.16%0.18%

-1.27%-0.10%

TCPIP MachineWKSET (V)DASD PAGE RATE (V)TOT CPU/CMD (V)CP CPU/CMD (V)VIRT CPU/CMD (V)DIAG 98/CMD (V)

27000

5.23602.36402.8720

5.102

27000

5.35502.39502.9600

5.117

00

0.11900.03100.0880

0.015

0.00%0.00%2.27%1.31%3.06%0.29%



Improved SMTP Server Capacity

Improved SMTP Server CapacityThe maximum throughput that can be handled by any given SMTP server virtualmachine has been substantially increased with TCP/IP 310 (see Figure 1). Forthe workload and system configuration described in this section, throughputincrease multiples ranging from 1.6 to 3.4 relative to TCP/IP 2.4 were observed.These improvements resulted from eliminating many of the SMTP 191 minidiskI/Os and from using the *SPL CP system service to read spool filesasynchronously.

Figure 1. SMTP throughput improvements

Workload: Each note consisted of 60 lines of text and was sent to threerecipients. These recipients were all on the same system, which was differentfrom the sending system.

Configuration: The measured system consisted of a 9121-480 (2-way) processorwith 256MB of central storage and no expanded storage. It was running VM/ESA2.3.0 and TCP/IP 2.4 except for SMTP MODULE, which was either at the 2.4 or310 level. The SMTP 191 minidisk was on a dedicated 3390 volume behind a3990-3 control unit with read caching but no DASD fast write. VM/ESA minidiskcaching was in effect. The 8 spool volumes were on RAMAC 2 Array SubsystemDASD.

The measured system was attached to a 16Mbit IBM Token Ring through a3172-3 Interconnect Controller. A packet (MTU) size of 4000 bytes was specified.The test notes were sent to or received from one to four additional systems onthe same token ring. Two of these additional systems were also VM/ESA 2.3.0systems with 3172-3 attachment to the token ring. The other two additionalsystems were RS/6000 model 250s running AIX 4.1.4.



Measurement Method: All note traffic through the measured system washandled by one SMTP server virtual machine. For any given measurement, allnotes were either sent from the measured system (send runs) out to recipientson the additional systems or all notes were sent from the additional systems torecipients on the measured system (receive runs).

Multiple additional systems were used (instead of just one) because throughputbetween any two systems is often limited by network latency. This is becauseSMTP maintains just one TCP connection between any two systems andcommunications are serialized on that connection. Of primary interest in thesemeasurements was maximum throughput that can be delivered by one SMTPserver when not constrained by the number of connections to other systems.

For send runs, note files in batch SMTP format were punched to the SMTPserver from a separate virtual machine on the measured system. Any givennote was sent to three recipients on one of the target systems. Notes were sentwith equal frequency to all used target systems in order to evenly distribute theload. The number of target systems was varied from run to run in order todetermine how many were necessary such that the number of connections didnot limit maximum throughput. The applied load was varied from run to run byadjusting the rate at which the sending virtual machine would punch notes to theSMTP server.

For receive runs, note files were sent from one or more of the additional systemsto three recipients on the measured system. Notes arrived with roughly equalfrequency from each of the sending systems. As with the send runs, the numberof sending systems was varied from run to run in order to ensure that throughputwas not limited by having too few connections. The applied load was variedfrom run to run by adjusting the rate at which each of the sending systems wouldtransmit notes to the measured system.

All measurements were taken over a 3 minute interval after the desired level ofnote traffic had been started. The primary measure was the number of notesdelivered per second to the recipients. This was determined by counting thenumber of “Delivered Note” messages in the SMTP log that occurred during themeasurement interval and dividing that by the measurement interval times 3 (thenumber of recipients per note). That is, one note delivered to its 3 recipientswas counted as one note delivered.

Maximum SMTP throughput is significantly affected by whether the SMTP log isto disk or spool (virtual console) because this affects the SMTP minidisk I/Os thatare done. Accordingly, maximum throughput was determined for both cases.Except for log placement, the default SMTP CONFIG settings were used.



Measurement Results: The measurement results are summarized in Table 23and Table 24.

Table 23. SMTP Maximum Throughput Results: Send Notes

runidSMTP levelSMTP logreceiving systems

S4SR30222.4

spool3

S4SR30212.4

disk3

SHSR4053310

spool4

SHSR4052310

disk4

delivered notes/secratio vs 2.4 log to spoolratio vs 2.4 log to disk

SMTP CPU-sec/secNAMESRV CPU-sec/secTCPIP CPU-sec/secms SMTP TCPU/note

ratio vs 2.4 log to spoolratio vs 2.4 log to disk

ms NAMESRV TCPU/notems TCPIP TCPU/notems TOTAL TCPU/noteSMTP virtual IOs/note

1.141.000.620.110.070.0696.81.001.1960.852.4

212.258.3

1.841.611.000.150.110.0981.10.841.0062.348.6

193.843.9

3.863.392.100.290.250.1875.60.780.9365.747.4

190.49.7

3.873.392.100.270.250.1871.00.730.8865.347.5

185.49.6

spool IOs/sec% spool readmsec/spool IOminidisk IOs/secmsec/minidisk IO

14.954

2.54717

21.262

2.85114

27.445

3.23616

26.147

3.03617

minidisk IOs/noteratio vs 2.4 log to spoolratio vs 2.4 log to disk

minidisk IO-sec/noteratio vs 2.4 log to spoolratio vs 2.4 log to disk

spool read IOs/secspool read IOs/notespool read IO-sec/secsynch spool read IO-sec/secspool write IOs/secspool write IOs/notespool write IO-sec/sec

41.21.001.490.701.001.81

8.07.1

0.020.02

6.96.0

0.02

27.70.671.000.390.551.0013.1

7.10.040.04

8.14.4

0.02

9.30.230.340.150.210.3812.3

3.20.040.0015.1

3.90.05

9.30.230.340.160.230.4112.3

3.20.040.0013.8

3.60.04

synch spool IO-sec/secminidisk IO-sec/secSMTP CPU-sec/secSMTP waiting for CPU-sec/secserialized SMTP-sec/sec

0.040.800.110.020.97

0.060.710.150.020.94

0.050.580.290.040.96

0.040.610.270.040.96



The CPU usage data were obtained from the CP QUERY TIME command. TheSMTP virtual I/O data were obtained from the CP INDICATE USER command.The minidisk and spool real I/O rates and access times were obtained fromRTM/ESA.

Calculations:

Minidisk IO-sec/sec was calculated as minidisk IOs/sec x 0.001 xmsec/minidisk IO.

Spool read IOs/sec was calculated as spool IOs/sec x 0.01 x % spool read.

Spool read IO-sec/sec was calculated as spool read IOs/sec x 0.001 xmsec/spool IO.

Synch spool read IO-sec/sec was calculated as equal to spool readIO-sec/sec for 2.4 SMTP and zero for 310 SMTP.

Spool write calculations were done in the same manner as the spool readcalculations, with spool write IOs/sec being calculated as spool IOs/sec -spool read IOs/sec.

Table 24. SMTP Maximum Throughput Results: Receive Notes

runidSMTP levelSMTP logsending systems

S4RR10412.4

spool1

S4RRD0412.4

disk1

SHRR3023310

spool3

SHRR3022310

disk3

delivered notes/secratio vs 2.4 log to spoolratio vs 2.4 log to disk

SMTP CPU-sec/secNAMESRV CPU-sec/secTCPIP CPU-sec/secms SMTP TCPU/note

ratio vs 2.4 log to spoolratio vs 2.4 log to disk

ms NAMESRV TCPU/notems TCPIP TCPU/notems TOTAL TCPU/noteSMTP virtual IOs/note

1.391.000.610.140.010.0498.51.001.03

4.826.9

132.243.4

2.281.641.000.220.010.0696.00.971.00

5.226.4

129.631.3

2.952.121.300.330.010.10

113.01.151.18

5.034.8

155.18.2

3.572.571.570.390.020.12

108.51.101.13

5.033.0

148.85.1

spool IOs/sec% spool readmsec/spool IOminidisk IOs/secmsec/minidisk IO

9.20.15.54016

14.80

5.53614

19.32

5.52317

22.22

5.51815

minidisk IOs/noteratio vs 2.4 log to spoolratio vs 2.4 log to disk

minidisk IO-sec/noteratio vs 2.4 log to spoolratio vs 2.4 log to disk

spool read IOs/secspool read IOs/notespool read IO-sec/secsynch spool read IO-sec/secspool write IOs/secspool write IOs/notespool write IO-sec/sec

28.81.001.820.461.002.08

0.00.0

0.000.00

9.26.6

0.05

15.80.551.000.220.481.00

0.00.0

0.000.0014.8

6.50.08

7.80.270.490.130.290.60

0.40.1

0.000.0018.9

6.40.10

5.00.180.320.080.160.34

0.40.1

0.000.0021.8

6.10.12

synch spool IO-sec/secminidisk IO-sec/secSMTP CPU-sec/secSMTP waiting for CPU-sec/secserialized SMTP-sec/sec

0.050.640.140.010.83

0.080.500.220.010.81

0.100.390.330.010.83

0.120.270.390.010.79



Measurement Discussion: When there are sufficient connections, maximumSMTP throughput is almost entirely determined by the combined effects of fourserializing factors: waiting to use the CPU, using the CPU, doing I/O (allsynchronous) to the SMTP 191 minidisk, and doing synchronous spool I/O. Eachof these factors is mutually exclusive within the SMTP virtual machine. Forexample, when SMTP is waiting for minidisk I/O to complete, it is not waiting forthe CPU, using the CPU, or doing synchronous spool I/O. Waiting for page readI/O can also be a serializing factor but there was no paging during any of themeasurement intervals.

We can think of the total capacity of an SMTP server virtual machine as being1.00 SMTP elapsed seconds per second. Each of the above four componentsuses up a certain amount of this capacity. This capacity utilization can becalculated from the measured data for all factors except waiting for CPU. Thesecalculations are shown in the results tables. In the case of synchronous spoolI/O, the calculations assume that all spool write I/Os are synchronous while, inreality, some spool write I/Os are asynchronous. As such, the synchronousspool I/O calculation represents an upper bound.

The waiting for CPU component can be estimated from the user state dataprovided in the domain 4 record 4 CP monitor record and shown as the “Waitingon CPU” column in the USER_STATES VMPRF report. This information, collectedonly for certain runs, is the basis for the “SMTP waiting for CPU-sec/sec”estimates shown in the results tables.

For the send cases, the sum of the four serializing factors (serializedSMTP-sec/sec) is close to 1.00, indicating that these factors are sufficient toaccount for the observed maximum throughputs. For the receive cases, the sumof the four serializing factors adds up to only 0.79 to 0.83. This indicates thatalthough they do account for most of the observed maximum throughput, theremay be one or more additional factors involved as well.

The results show that on the measured configuration, most of the throughputgains arose from the large decrease in I/Os to the SMTP 191 minidisk. Theamount of improvement due to this change will be smaller on systems havingshorter DASD access times for the SMTP 191 minidisk. This would normally bethe case, for example, in cases where write caching is in effect. The send casesalso derived some improvement from the use of *SPL to read the spool filesasynchronously. The amount of improvement due to this change would be largeron systems with longer spool access times.

If much of the note traffic is between two systems, the connection serializationdescribed earlier can limit throughput.

Send example: Run SHSR4053 showed a maximum throughput of 3.86 notessent per second. Four different receiving systems were used for this run. Acorresponding measurement with just one receiving system (SHSR1021, notshown), yielded a throughput of 1.73 notes sent per second.

Receive example: Run SHRR3023 showed a maximum throughput of 2.95notes received per second. Three different sending systems were used forthis run. A corresponding measurement with just one sending system(SHRR1041, not shown), yielded a throughput of 2.11 notes received persecond.


OfficeVision 1.4.0

Equivalent throughput results were obtained when running SMTP MODULE at the310 level on TCP/IP 2.4 as compared to running all of the TCP/IP code at the 310level.

The significant NAMESRV CPU usage illustrates that the resolution of hostnames to internet addresses is an important part of SMTP processing. SMTP′sname resolution requests are asynchronous, so this does not serialize SMTP.However, this does affect throughput per connection and overall efficiency.Because of this, we recommend that you have a domain name server defined aspart of the TCP/IP configuration when significant SMTP traffic is anticipated. Acaching-only domain name server should be sufficient.

OfficeVision 1.4.0This section summarizes the results from a pair of measurements obtained toobserve the effects of migrating from OfficeVision 1.3.0 to OfficeVision 1.4.0 forthe IBM Office Benchmark (IOB). Both measurements were made using VM/ESA2.2.0 running on a 9121-480.

Workload: IOB


Processor model: 9121-480Processors used: 2Storage



DASD:


Communications:

Type ofDASD

ControlUnit



3390-3 RAMAC 2 4 8 163390-2 3990-2 4 6 63390-2 3990-3 2 2 R3390-2 3990-3 4 10 2 7 R


Control Unit Speed

3088-08 1 NA 4.5MB


OfficeVision 1.4.0


Driver: TPNSThink time distribution: IOBCMS block size: 4KB

Virtual Machines:

Note: IBCENTRL = Y is an OV/VM option causing the users ′ inbaskets to residein the mail box machines and not on the users′ A-disks for convenience ofworkload setup.

Note: The OV/VM ESA Calendar Feature is not installed.

Measurement Discussion: Overall performance decreased slightly, mostly as aresult of changes required for 31 bit support. External response time (AVGLAST(T)) increased by 5%, while internal throughput (ITR(H)) decreased by1.1%.

The 31 bit support means that the OFSSEG shared segment can now be placedabove the 16MB line, freeing space below the line that can be used for otherpurposes. The EPUYSSEG shared segment (contains the OV/VM mailboxmanager code) could already be placed above the line.

This comparison was made using the uncompiled version of the REXX execsprovided by OfficeVision. (OfficeVision/VM provides both uncompiled andcompiled forms for most of its REXX execs.) A significant percentage of the CPUusage increase is from increased time required to interpret these execs.Therefore, the precentage increase in CPU usage relative to OfficeVision 1.3.0should be appreciably smaller when using the compiled version of these execs.

Measurements from the VM/ESA 2.2.0 Performance Report indicate thatOfficeVision 1.2.0 and 1.3.0 have equivalent performance. Therefore, the resultsshown here also apply to migrations from OfficeVision 1.2.0 to 1.4.0.



Ennnn 10 Workload 2MB/XA 1000 QUICKDSP ONPRNTEAT1 1 Workload 2MB/XA 1000 QUICKDSP ONPROCAL 1 OV/VM 16MB/XA 3000 1600 QUICKDSP ONPRODBM 1 OV/VM 16MB/XA 3000 550 QUICKDSP ONPROMAIL 1 OV/VM 16MB/XA 3000 QUICKDSP ONPROMBX 1 OV/VM 16MB/XA 3000 QUICKDSP ON

IBCENTRL = YPROMBXnn 10 OV/VM 16MB/XA 3000 QUICKDSP ON

IBCENTRL = YSMART 1 RTM 32MB/XA 3 % 400 QUICKDSP ONVMCF 1 Monitor 4MB/XA 200 QUICKDSP ONVTAMXA 1 VTAM/VSCS 64MB/XA 10000 900 QUICKDSP ONWRITER 1 CP Monitor 2MB/XA 100 QUICKDSP ONUsers 2100 User 2MB/XA 100


OfficeVision 1.4.0

Table 25 (Page 1 of 2). Migration from OfficeVision 1.3.0 to OfficeVision 1.4.0 usingVM/ESA 2.2.0 on a 9121-480

OV/VM ReleaseVM/ESA ReleaseRun ID

1.3.02.2.0

L29V2102

1.4.02.2.0

L29V2103Difference %Difference


256MB0MB2100

102

256MB0MB2100

102


0.0480.5650.5440.5070.3740.528

0.0490.5870.5640.5260.3920.555

0.0010.0220.0200.0180.0180.027

2.08%3.89%3.68%3.65%4.95%5.11%


46.5033.1735.580.93239.6818.5232.201.0001.000

46.4033.1435.560.93239.2418.3131.690.9890.988

-0.09-0.03-0.020.000-0.44-0.21-0.51

-0.011-0.012

-0.19%-0.09%-0.06%-0.03%-1.10%-1.15%-1.58%-1.10%-1.15%


50.40250.31022.92321.36027.47928.949

50.96250.90223.04521.37327.91729.529

0.5600.5930.1220.0130.4380.580

1.11%1.18%0.53%0.06%1.59%2.00%


179.33179.00

89.6789.5097.77

103.0090.2190.0038.8141.00

1.831.74

181.21181.00

90.6190.5099.27

105.0090.3190.0039.7042.00

1.831.72

1.882.000.941.001.502.000.100.000.891.00

-0.01-0.01

1.05%1.12%1.05%1.12%1.53%1.94%0.11%0.00%2.29%2.44%

-0.48%-0.81%


2388KB350KB

7955068

26.2141

61351.00

1534

2388KB350KB

8155050

26.2144

61361.00

1552

0KB0KB

2-180.0

31

0.0018

0.00%0.00%2.53%

-0.03%-0.03%2.13%0.02%

-0.02%1.17%


OfficeVision 1.4.0

Table 25 (Page 2 of 2). Migration from OfficeVision 1.3.0 to OfficeVision 1.4.0 usingVM/ESA 2.2.0 on a 9121-480

OV/VM ReleaseVM/ESA ReleaseRun ID

1.3.02.2.0

L29V2102

1.4.02.2.0

L29V2103Difference %Difference


256MB0MB2100

102

256MB0MB2100

102


607551

32.547172.500

4.84800

0.00021.276

627570

33.663178.100

5.00900

0.00021.345

2019

1.1175.6000.160

00

0.0000.069

3.29%3.45%3.43%3.25%3.31%

nanana

0.32%


35.060.00

34.930.00

-0.130.00

-0.37%na


85624.059

52614.784

9.93517.100

53.40.0

28656

2630.92

85223.961

53014.905

9.89617.000

53.40.0

28555

2630.92

-4-0.098

40.121

-0.039-0.100

0.00.0-1-10

0.00

-0.47%-0.41%0.76%0.82%

-0.39%-0.58%-0.05%

na-0.35%-1.79%0.00%0.00%


21.05389.898

4.40012.011

4.9891.6322.0601.435

10.7306.334

33.7270.667

132.91390.381

146.909

20.92289.393

4.41211.925

4.9811.6242.0601.410

10.7056.308

33.5090.718

133.04990.474

146.605

-0.131-0.5050.013

-0.086-0.009-0.0080.000

-0.025-0.025-0.026-0.2180.0510.1370.093

-0.305

-0.62%-0.56%0.28%

-0.72%-0.17%-0.49%0.02%

-1.73%-0.23%-0.40%-0.65%7.67%0.10%0.10%

-0.21%


8905.16842.01433.1541

1.436

8905.18712.03113.1560

1.411

00.01870.01680.0019-0.025

0.00%0.36%0.83%0.06%

-1.75%



OfficeVision SFS A-Directory Support

OfficeVision SFS A-Directory SupportOfficeVision 1.4.0 supports the use of an SFS directory as filemode A2. One ofthe primary benefits of this support is that it enables OfficeVision/VMinstallations to significantly reduce their DASD space requirements by movinguser files from minidisks to SFS. DASD space savings exceeding 30% havebeen reported in the past for non-OfficeVision CMS systems. Theseimprovements and all other SFS benefits need to be traded off against the factthat SFS uses additional processor time and real storage relative to minidisks.

This section quantifies the performance effects of replacing the A-minidisk withan SFS A-directory for the case of the IOB workload running on a 9121-480processor. It then provides a generalized method for estimating the percentageincrease in processor usage for moving a given amount of minidisk activity toSFS filecontrol directories.

Workload: IOB


Processor model: 9121-480Processors used: 2Storage



DASD:

Note: R next to the DASD counts means basic cache enabled; W means DASDfast write (and basic cache) enabled.

Communications:

Type ofDASD

ControlUnit



3390-2 3990-2 4 6 4 63390-2 3990-3 2 2 R3390-2 3990-3 4 10 4 2 16 R 7 R


Control Unit Speed

3088-08 1 NA 4.5MB

2 This information first appeared in an update to the VM/ESA Version 2 Release 2.0 Performance Report. It is repeated here forthose who read the original report but may have missed the update.




Driver: TPNSThink time distribution: IOBCMS block size: 4KB

Virtual Machines:

Note: IBCENTRL = Y is an OV/VM option causing the users ′ inbaskets to residein the mail box machines and not on the users′ A-disks for convenience ofworkload setup.

Note: The OV/VM ESA Calendar Feature is not installed.

Measurement Discussion: An OfficeVision measurement was obtained with eachuser ′s SFS root directory used for that user′s A-filemode. The number of users(1500) was chosen such that average processor utilization was approximately90%. Table 26 compares this measurement to an equivalent measurementwhere each user′s A-filemode was a minidisk. Both measurements were madeusing OfficeVision 1.3.0.3



Ennnn 10 Workload 2MB/XA 1000 QUICKDSP ONPRNTEAT1 1 Workload 2MB/XA 1000 QUICKDSP ONPROCAL 1 OV/VM 16MB/XA 3000 1600 QUICKDSP ONPRODBM 1 OV/VM 16MB/XA 3000 550 QUICKDSP ONPROMAIL 1 OV/VM 16MB/XA 3000 QUICKDSP ONPROMBX 1 OV/VM 16MB/XA 3000 QUICKDSP ON

IBCENTRL = YPROMBXnn 10 OV/VM 16MB/XA 3000 QUICKDSP ON

IBCENTRL = YCRRSERV1 1 SFS 16MB/XC 100ROSERV1 1 SFS 64MB/XC 100 QUICKDSP ONRWSERVn 2 SFS 64MB/XC 1500 1300 QUICKDSP ONSMART 1 RTM 32MB/XA 3 % 400 QUICKDSP ONVMCF 1 Monitor 4MB/XA 200 QUICKDSP ONVTAMXA 1 VTAM/VSCS 64MB/XA 10000 900 QUICKDSP ONWRITER 1 CP Monitor 2MB/XA 100 QUICKDSP ONUsers 2100/1500 User 2MB/XA 100

3

OfficeVision 1.3.0 does not support an SFS directory as filemode A but the FS8F workload does run correctly in thatenvironment. Similar comparative results can be expected using OfficeVision 1.4.0.



Table 26 (Page 1 of 3). OfficeVision performance with an SFS A-directory

Filemode AOV/VM ReleaseVM/ESA ReleaseRun ID

Minidisk1.3.02.2.0

L29V2101

SFS1.3.02.2.0

L29V1500



256MB0MB2100

102

256MB0MB1500

102

-600 -28.57%


0.0550.6270.5890.5620.4790.667

0.1210.7280.6830.6600.5250.759

0.0660.1010.0940.0980.0450.092

120.00%16.11%15.96%17.39%

9.48%13.78%


46.3033.9135.530.95439.3418.9232.931.0001.000

46.3924.5525.410.96628.4513.7524.170.7230.727

0.09-9.36

-10.120.012

-10.89-5.16-8.76

-0.277-0.273

0.18%-27.60%-28.48%

1.23%-27.68%-27.30%-26.60%-27.68%-27.30%


50.83350.37923.16521.39027.66828.989

70.29170.44232.12930.30238.16240.140

19.45720.064

8.9648.912

10.49311.151

38.28%39.83%38.70%41.67%37.92%38.47%


180.61179.00

90.3189.5098.31

103.0090.6890.0038.7741.00

1.841.74

178.61179.00

89.3189.5096.97

102.0089.5890.0041.7444.00

1.841.75

-2.000.00

-1.000.00

-1.34-1.00-1.100.002.973.000.000.02

-1.11%0.00%

-1.11%0.00%

-1.36%-0.97%-1.21%0.00%7.67%7.32%0.26%0.98%


2804KB350KB

7955072

26.2141

60100.98

1547

2804KB350KB

9257221

38.1171

43980.99

1707

0KB0KB

13214911.9

30-1612

0.01160

0.00%0.00%

16.46%3.90%

45.46%21.28%

-26.82%1.00%

10.34%





Minidisk1.3.02.2.0

L29V2101

SFS1.3.02.2.0

L29V1500



256MB0MB2100

102

256MB0MB1500

102

-600 -28.57%


614558

32.986176.400

4.96500

0.00021.418

504456

37.779143.600

5.65100

0.00021.329

-110-102

4.794-32.800

0.68600

0.000-0.089

-17.92%-18.28%14.53%

-18.59%13.83%

nanana

-0.41%


40.830.00

35.740.00

-5.100.00

-12.48%na


85724.120

53415.02910.06520.900

55.00.0

29059

2670.92

67626.603

43317.04011.38917.700

68.00.0

24452

2150.87

-1812.483-101

2.0111.324

-3.20013.0

0.0-46

-7-52

-0.05

-21.12%10.29%

-18.91%13.38%13.16%

-15.31%23.69%

na-15.86%-11.86%-19.48%

-5.43%


21.18190.422

4.55112.076

4.7371.4672.0601.295

10.9546.382

34.2430.673

130.67690.166

148.125

50.81885.133

5.51512.822

5.0721.6362.1111.6196.0185.406

32.0500.685

168.472124.669164.182

29.638-5.2890.9640.7460.3340.1690.0520.324

-4.936-0.976-2.1930.012

37.79634.50316.057

139.93%-5.85%21.18%

6.18%7.06%

11.54%2.50%

25.05%-45.06%-15.29%

-6.40%1.79%

28.92%38.27%10.84%


8905.09731.98583.1115

1.290

9005.53132.14263.3888

1.619

100.43400.15680.2773

0.329

1.12%8.51%7.90%8.91%

25.50%



The results show the same kinds of performance effects that have beenobserved for the FS8F CMS-intensive workload. See Table 6 on page 26 for anexample FS8F comparison. Processor usage per command (PBT/CMD(H))increased by 38%. This is higher than the 19% increase observed for the FS8Fworkload. The reason for this is that a correspondingly larger amount ofminidisk activity has been moved to SFS filecontrol directories in the IOBworkload case.

A rule of thumb has been developed, based on earlier FS8F workload results, forestimating the percentage increase in processor usage for migrating a givenamount of minidisk activity to SFS filecontrol directories:

Assume a 6% increase in total system CPU usage for every virtual I/O permillion instructions executed that is moved from minidisks to SFS filecontroldirectories.

A VM/ESA installation can use this method to estimate the effect of their ownplanned usage of SFS on their system′s total processor requirements. Toillustrate the application of this rule of thumb, we′ ll use it to estimate thepercentage increase in CPU/command for the comparison shown in this sectionwhere we replace the users′ A-disks with SFS directories.

Note that the rule of thumb is based on virtual I/Os, not real I/Os. Real I/Osinclude the effects of minidisk caching and can therefore be much lower. Sincenot all virtual I/Os are minidisk I/Os and not all minidisks will be migrated toSFS, it would be ideal to have a breakdown of virtual I/Os by minidisk from thecurrent system in order to provide input to the estimation formula. Typically,however, I/Os are only broken down on a DASD volume basis so you need toapply some judgement for volumes where only some of the I/O activity is comingfrom minidisks that are to be moved to SFS. SEEKS domain monitor data can beused to obtain a breakdown of I/O rate by minidisk for these mixed volumes.You should bear in mind, however, that this is a breakdown of real I/Os, notvirtual I/Os.



Minidisk1.3.02.2.0

L29V2101

SFS1.3.02.2.0

L29V1500



256MB0MB2100

102

256MB0MB1500

102

-600 -28.57%


nananananananana

262314.514

6.1418.3735.5776.6830.0820.153




One good source of virtual I/Os on a volume basis is from the “SSCH+RSCHPlus Avoid Rate” column in VMPRF′s DASD_BY_ACTIVITY report. This is thereal I/O rate plus the additional I/O rate (if any) that has been avoided by thepresence of minidisk caching. In our example, all user A-disks are defined onMDSKnn volumes and there are no additional sources of I/O activity on thosevolumes. Accordingly, all we need to do is sum the “Plus Avoided” column overall 16 MDSKnn volumes. The result is 218.5 VIOs per second, as shown inFigure 2.

<-----Device------> <---------SSCH+RSCH-------->

Mini- On- PlusNum- Volume Control disk line Plus Avoid ber Serial Type Unit Links Secs Count Rate Avoided Rate

FB82 MDSK11 3390-2 3990-3 130 1800 13973 7.8 26515 14.7F900 MDSK01 3390-2 3990-3 131 1800 13932 7.7 25819 14.3FB80 MDSK09 3390-2 3990-3 130 1800 13788 7.7 25328 14.1F905 MDSK06 3390-2 3990-3 129 1800 14197 7.9 25437 14.1F907 MDSK08 3390-2 3990-3 129 1800 13127 7.3 25008 13.9FB81 MDSK10 3390-2 3990-3 130 1800 13087 7.3 24903 13.8F903 MDSK04 3390-2 3990-3 129 1800 13061 7.3 24667 13.7FB83 MDSK12 3390-2 3990-3 129 1800 13070 7.3 24717 13.7F904 MDSK05 3390-2 3990-3 129 1800 12779 7.1 24227 13.5F901 MDSK02 3390-2 3990-3 130 1800 13124 7.3 24358 13.5F906 MDSK07 3390-2 3990-3 129 1800 12737 7.1 24115 13.4FB86 MDSK15 3390-2 3990-3 128 1800 13123 7.3 24119 13.4FB84 MDSK13 3390-2 3990-3 130 1800 13037 7.2 23799 13.2FB85 MDSK14 3390-2 3990-3 130 1800 12901 7.2 23750 13.2FB87 MDSK16 3390-2 3990-3 128 1800 12623 7.0 23556 13.1F902 MDSK03 3390-2 3990-3 129 1800 12390 6.9 23291 12.9

Total VIO/sec moved to SFS --> 218.5

Figure 2. Minidisk volumes from the L29V2101 DASD_BY_ACTIVITY VMPRF report.

Note: Not all of the report′s columns are shown.

The L29V2101 base measurement ran at 90% processor utilization on a 9121-480.A 9121-480 is roughly a 38 MIPS machine (varies with workload). That means itcan execute about 38 million instructions (MI) per wall clock second if the systemis running at 100% utilization. In our case, it is running at 90% utilization, so itis executing 0.9*38 = 34 MI per second. 218.5 VIOs/sec / 34 MI/sec = 6.4 VIOs /MI. Applying the rule of thumb, 6% * 6.4 = 38%. This estimate is very close tothe 38.3% increase in PBT/CMD(H) that was actually observed.4

It is important to note that this method estimates the percentage increase inprocessor usage per unit work. It does not estimate the percentage increase inprocessor utilization, which also depends upon what happens to the rate atwhich work is handled by the system.

4 It is just by chance that the estimated and observed values are in such close agreement in this example. However, this ruleof thumb should come within plus or minus 5% of the actual value most of the time. That means, in our example, that the ruleof thumb estimates that the true percentage increase should be somewhere between 36% and 40%.



Note that the rule of thumb only applies to minidisk activity that migrated to SFSfilecontrol directories. Any minidisk activity that is being migrated to SFSdircontrol directories mapped to VM data spaces should be ignored becausesuch a migration normally results in negligible performance differences.

There is a reciprocal relationship between processor usage (per unit work) andthe number of users that can be supported from a processor capacity standpoint.In our example, we estimated a 38% increase in processor usage or,equivalently, processor usage will be 1.38 times larger. From that, we canestimate that the system can support 1/1.38 = 0.72 times as many users at thesame processor utilization after the proposed migration to SFS — a 28%reduction. This corresponds well with the measured 28.6% reduction.


CMS-Intensive (FS8F)

Appendix A. Workloads

The workloads that were used to evaluate VM/ESA 2.3.0 are described in thisappendix.


Workload DescriptionFS8F simulates a CMS user environment, with variations simulating a minidiskenvironment, an SFS environment, or some combination of the two. Table 27shows the search-order characteristics of the two environments used formeasurements discussed in this document.

The measurement environments have the following characteristics in common:

• A Bactrian-distribution think time averaging 30 seconds is used. (See“Glossary of Performance Terms” on page 94 for an explanation of Bactriandistribution.)

• The workload is continuous in that scripts, repeated as often as required, arealways running during the measurement period.

• Teleprocessing Network Simulator (TPNS) simulates users for the workload.TPNS runs in a separate processor and simulates LU2 terminals. User traffictravels between the processors through 3088 multisystem channelcommunication units.

Table 27. FS8F workload characteristics

Filemode ACCESSNumberof Files FS8F0R FS8FMAXR

ABCDEFGSY

R/WR/WR/OR/WR/OR/OR/OR/OR/O

1000

500500500500500

mn

minidiskminidiskminidiskminidiskminidiskminidiskminidiskminidiskminidisk

SFSSFSSFS (DS)SFSSFS (DS)SFS (DS)SFS (DS)minidiskminidisk

Note: m and n are the number of files normally found on the the S- andY-disks respectively. (DS) signifies the use of VM Data Spaces.

FS8F VariationsTwo FS8F workload variants were used for measurements, one forminidisk-based CMS users, and the other for SFS-based CMS users.

FS8F0R Workload: All filemodes are accessed as minidisk; SFS is not used. Allof the files on the C-disk have their FSTs saved in a shared segment.



FS8FMAXR Workload: All file modes, except S and Y (which SFS does notsupport), the HELP minidisk, and T-disks that are created by the workload, areaccessed as SFS directories. The CMSFILES shared segment is used. Allread-only SFS directories are defined with PUBLIC READ authority and aremapped to VM data spaces. The read/write SFS directory accessed as file modeD is defined with PUBLIC READ and PUBLIC WRITE authority. The read/writeSFS directories accessed as file modes A and B are private directories.

FS8F Licensed ProgramsThe following licensed programs were used in the FS8F measurementsdescribed in this document:

• VS COBOL II Compiler and Library V1R4M0

• Document Composition Facility V1R4M0

• VS FORTRAN Compiler/Library/Debug V2R5M0

• IBM High Level Assembler V1R2M0

• OS PL/I V2R3M0 Compiler & Library

• C & PL/I Common Library V1R2M0

• VTAM V3R4M1

• NCP V5R4M0

Measurement MethodologyA calibration is made to determine how many simulated users are required toattain the desired processor utilization for the baseline measurement. Thatnumber of users is used for all subsequent measurements on the sameprocessor and for the same environment.

The measurement proceeds as follows:

• All of the users are logged on by TPNS.

• A script is started for each user after a random delay of up to 15 minutes.(The random delay prevents all users from starting at once.)

• A stabilization period (the length depending on the processor used) isallowed to elapse so that start-up anomalies and user synchronization areeliminated.

• At the end of stabilization, measurement tools are started simultaneously togather data for the measurement interval.

• At the end of the measurement interval, the performance data is reducedand analyzed.

FS8F Script DescriptionFS8F consists of 3 initialization scripts and 17 workload scripts. The LOGESAscript is run at logon to set up the required search order and CMS configuration.Then users run the WAIT script, during which they are inactive and waiting tostart the CMSSTRT script. The CMSSTRT script is run to stagger the start ofuser activity over a 15 minute interval. After the selected interval, each userstarts running a general workload script. The scripts are summarized inTable 28 on page 80.

Appendix A. Workloads 79


Table 28. FS8F workload script summary

Script Name % Used Script Description

LOGESAWAITCMSSTRTASM617FASM627FXED117FXED127FXED137FXED147FCOB217FCOB417FFOR217FFOR417FPRD517FDCF517FPLI317FPLI717FWND517FWND517FLHLP517F

***555

101010

55555555825

Logon and InitializationWait stateStagger start of user activityAssemble (HLASM) and RunAssemble and RunEdit a VS BASIC ProgramEdit a VS BASIC ProgramEdit a COBOL ProgramEdit a COBOL ProgramCOBOL CompileRun a COBOL ProgramVS FORTRAN CompileFORTRAN RunProductivity Aids SessionEdit and Script a FilePL/I Optimizer SessionPL/I Optimizer SessionRun Windows with IPL CMSRun Windows with LOGON/LOGOFFUse HELP

Note: Scripts with an asterisk (*) in the “% Used” column are run only onceeach for each user during initialization.



The following are descriptions of each script used in the FS8F workload.

LOGESA: Initialization Script

LOGON useridSET AUTOREAD ONIF FS8F0R workloadTHEN

Erase extraneous files from A-diskRun PROFILE EXEC to access correct search order,

SET ACNT OFF, SPOOL PRT CL D, and TERM LINEND OFFELSE

Erase extraneous files from A-directoryRun PROFILE EXEC to set correct search order, SET ACNT OFF,

SPOOL PRT CL D, and TERM LINEND OFFENDClear the screenSET REMOTE ON

WAIT: Ten-Second PauseLeave the user inactive in a 10-second wait loop.

CMSSTRT: Random-Length PauseDelay, for up to 15 minutes, the start for each user to prevent all users fromstarting scripts at the same time.

ASM617F: Assemble (HLASM) and Run

QUERY reader and printerSPOOL PRT CLASS DXEDIT an assembler file and QQUITGLOBAL appropriate MACLIBsLISTFILE the assembler fileAssemble the file using HLASM (NOLIST option)Erase the text deckRepeat all the above except for XEDITReset GLOBAL MACLIBsLoad the text file (NOMAP option)Generate a module (ALL and NOMAP options)Run the moduleLoad the text file (NOMAP option)Run the module 2 more timesErase extraneous files from A-disk



ASM627F: Assemble (F-Assembler) and Run

QUERY reader and printerClear the screenSPOOL PRT CLASS DGLOBAL appropriate MACLIBsLISTFILE assembler fileXEDIT assembler file and QQUITAssemble the file (NOLIST option)Erase the text deckReset GLOBAL MACLIBsLoad the TEXT file (NOMAP option)Generate a module (ALL and NOMAP options)Run the moduleLoad the text file (NOMAP option)Run the moduleLoad the text file (NOMAP option)Run the moduleErase extraneous files from A-diskQUERY DISK, USERS, and TIME

XED117F: Edit a VS BASIC Program

XEDIT the programGet into input modeEnter 29 input linesQuit without saving file (QQUIT)

XED127F: Edit a VS BASIC Program

Do a FILELISTXEDIT the programIssue a GET commandIssue a LOCATE commandChange 6 lines on the screenIssue a TOP and BOTTOM commandQuit without saving fileQuit FILELISTRepeat all of the above statements, changing 9 lines instead of 6 and

without issuing the TOP and BOTTOM commands

XED137F: Edit a COBOL Program

Do a FILELISTXEDIT the programIssue a mixture of 26 XEDIT file manipulation commandsQuit without saving fileQuit FILELIST



XED147F: Edit a COBOL Program

Do a FILELISTXEDIT the programIssue a mixture of 3 XEDIT file manipulation commandsEnter 19 XEDIT input linesQuit without saving fileQuit FILELIST

COB217F: Compile a COBOL Program

Set ready message shortClear the screenLINK and ACCESS a diskQUERY link and diskLISTFILE the COBOL programInvoke the COBOL compilerErase the compiler outputRELEASE and DETACH the linked diskSet ready message longSET MSG OFFQUERY SETSET MSG ONSet ready message shortLINK and ACCESS a diskLISTFILE the COBOL programRun the COBOL compilerErase the compiler outputRELEASE and DETACH the linked diskQUERY TERM and RDYMSGSet ready message longSET MSG OFFQUERY setSET MSG ONPURGE printer



COB417F: Run a COBOL Program

Define temporary disk space for 2 disks using an EXECClear the screenQUERY DASD and format both temporary disksEstablish 4 FILEDEFs for input and output filesQUERY FILEDEFsGLOBAL TXTLIBLoad the programSet PER InstructionStart the programDisplay registersEnd PERIssue the BEGIN commandQUERY search of minidisksRELEASE the temporary disksDefine one temporary disk as anotherDETACH the temporary disksReset the GLOBALs and clear the FILEDEFs

FOR217F: Compile 6 VS FORTRAN Programs

NUCXDROP NAMEFIND using an EXECClear the screenQUERY and PURGE the readerCompile a FORTRAN programIssue INDICATE commandsCompile another FORTRAN programIssue INDICATE commandsCompile another FORTRAN programIssue INDICATE commandClear the screenCompile a FORTRAN programIssue INDICATE commandsCompile another FORTRAN programIssue INDICATE commandsCompile another FORTRAN programClear the screenIssue INDICATE commandErase extraneous files from A-diskPURGE the printer

FOR417F: Run 2 FORTRAN Programs

SPOOL PRT CLASS DClear the screenGLOBAL appropriate text librariesIssue 2 FILEDEFs for outputLoad and start a programRename output file and PURGE printerRepeat above 5 statements for two other programs, except

erase the output file for one and do not issue spool printerList and erase output filesReset GLOBALs and clear FILEDEFs



PRD517F: Productivity Aids Session

Run an EXEC to set up names file for userClear the screenIssue NAMES command and add operatorLocate a user in names file and quitIssue the SENDFILE commandSend a file to yourselfIssue the SENDFILE commandSend a file to yourselfIssue the SENDFILE commandSend a file to yourselfIssue RDRLIST command, PEEK and DISCARD a fileRefresh RDRLIST screen, RECEIVE an EXEC on B-disk, and quitTRANSFER all reader files to punchPURGE reader and punchRun a REXX EXEC that generates 175 random numbersRun a REXX EXEC that reads multiple files of various sizes from

both the A-disk and C-diskErase EXEC off B-diskErase extraneous files from A-disk

DCF517F: Edit and SCRIPT a File

XEDIT a SCRIPT fileInput 25 linesFile the resultsInvoke SCRIPT processor to the terminalErase SCRIPT file from A-disk

PLI317F: Edit and Compile a PL/I Optimizer Program

Do a GLOBAL TXTLIBPerform a FILELISTXEDIT the PL/I programRun 15 XEDIT subcommandsFile the results on A-disk with a new nameQuit FILELISTEnter 2 FILEDEFs for compileCompile PL/I program using PLIOPTErase the PL/I programReset the GLOBALs and clear the FILEDEFsCOPY names file and RENAME itTELL a group of users one pass of script runERASE names filePURGE the printer



PLI717F: Edit, Compile, and Run a PL/I Optimizer Program

Copy and rename the PL/I program and data file from C-diskXEDIT data file and QQUITXEDIT a PL/I fileIssue RIGHT 20, LEFT 20, and SET VERIFY ONChange two linesChange filename and file the resultCompile PL/I program using PLIOPTSet two FILEDEFs and QUERY the settingsIssue GLOBAL for PL/I transient libraryLoad the PL/I program (NOMAP option)Start the programType 8 lines of one data fileErase extraneous files from A-diskErase extra files on B-diskReset the GLOBALs and clear the FILEDEFsTELL another USERID one pass of script runPURGE the printer

WND517F: Use Windows

SET FULLSCREEN ONTELL yourself a message to create windowQUERY DASD and readerForward 1 screenTELL yourself a message to create windowDrop window messageScroll to top and clear windowBackward 1 screenIssue a HELP WINDOW and choose Change Window SizeQUERY WINDOWQuit HELP WINDOWSChange size of window messageForward 1 screenDisplay window messageTELL yourself a message to create windowIssue forward and backward border commands in window messagePosition window message to another locationDrop window messageScroll to top and clear windowDisplay window messageErase MESSAGE LOGFILEIPL CMSSET AUTOREAD ONSET REMOTE ON



WND517FL: Use Windows with LOGON, LOGOFF

SET FULLSCREEN ONTELL yourself a message to create windowQUERY DASD and readerForward 1 screenTELL yourself a message to create windowDrop window messageScroll to top and clear windowBackward 1 screenIssue a help window and choose Change Window SizeQUERY WINDOWQuit help windowsChange size of window messageForward 1 screenDisplay window messageTELL yourself a message to create windowIssue forward and backward border commands in window messagePosition window message to another locationDrop window messageScroll to top and clear windowDisplay window messageErase MESSAGE LOGFILELOGOFF user and wait 60 secondsLOGON user on original GRAF-IDSET AUTOREAD ONSET REMOTE ON

HLP517F: Use HELP and Miscellaneous Commands

Issue HELP commandChoose HELP CMSIssue HELP HELPGet full description and forward 1 screenQuit HELP HELPChoose CMSQUERY menuChoose QUERY menuChoose AUTOSAVE commandGo forward and backward 1 screenQuit all the layers of HELPRELEASE Z-diskCompare file on A-disk to C-disk 4 timesSend a file to yourselfChange reader copies to twoIssue RDRLIST commandRECEIVE file on B-disk and quit RDRLISTErase extra files on B-diskErase extraneous files from A-disk


IBM Office Benchmark (IOB)


Workload DescriptionThe IBM Office Benchmark (IOB) Version 2.1 is a corporate-wide benchmarkdesigned to measure generic office system performance. It consists of the officeuser definition, the databases for calendars, the documents, the mail, and thework the office users do.

The IOB measurements included in this report use the DisplayWrite*/370 2.1.0and the OfficeVision/VM licensed programs.

Measurement MethodologyA calibration is made to determine how many simulated users are required toattain the desired processor utilization for the baseline measurement. Thatnumber of users is used for all subsequent measurements on the sameprocessor and for the same environment.

The measurement proceeds as follows:

• All of the users are logged on by TPNS and reach the OfficeVision mainmenu (the A00 screen).

• After a random delay of up to 10 minutes, each user selects a script andstarts. (The random delay prevents all users from starting at once).

• A stabilization period (45 minutes) is allowed to elapse so that start-upanomalies and user synchronization are eliminated.

• At the end of stabilization, measurement tools are started simultaneously togather data for the measurement interval (30 minutes).

• At the end of the measurement interval, the performance data are reducedand analyzed.

The IOB workload does not aim for a specific think time or use a certain thinktime distribution. Instead, the think time is dictated by the IOB workload. Thethink time includes an average two second delay between commands issued byTPNS, the built-in think times that are part of the IOB scripts, and the IOB scriptscheduling algorithm. When users finish running a script, the script schedulingalgorithm calculates how much time was spent running the script, subtracts thisnumber from ten minutes, and delays the user for the resulting amount of time.Thus, if a script completed in 7.9 minutes, the user would be delayed for 2.1minutes before starting the next script and this time would be included in theuser ′s think time.



IOB Script DescriptionsThe IOB workload consists of nine scripts (scenarios). These scripts are listed inTable 29 with their defined use factor.

The following is the list of tasks in each script within the IOB workload.

Send Note and Process Light Mail

• Create a note and send the note to two users.• View the note log.• View the first item, a note.• Delete the first item, a note.• Open Mail and View the In-Basket.• View the first item, a note.• Delete the first item, a note.

Send Note and Process Heavy Mail

• Create a note and send the note to two users.• View the note log.• View the first item, a note.• Delete the first item, a note.• Open Mail and View the In-Basket.• View the first item, a note.• Forward the first item to another user with an attachment.• Delete the original first item, a note.• View the eighth item in the mail list, a two page document.• Print the document.

View Individual Calendar

• View the user′s calendar for Wednesday of a defined week.

Update Individual Calendar

• View the user′s calendar for Wednesday of a defined week.• Delete a meeting.• Add a meeting.

View User Directory

• Search the user directory based on a random user name and view theperson ′s telephone number.

Table 29. IOB workload script summary

Script Name % Used Script Description

VMB2LMLVMB2HMLVMB2VCALVMB2UCALVMB2DIRVMB2CDOCVMB2UDOCVMB2EBVMB2ONOF

1717131320

7733

Send Note and Process Light MailSend Note and Process Heavy MailView Individual CalendarUpdate Individual CalendarView User DirectoryCreate Small Text DocumentRevise Small Text DocumentEnter/Exit OfficeLogoff/Logon System


VSE Guest (DYNAPACE)

Create Small Text Document

• Get a pre-stored document format.• Key in a two-page document.• Save the document.• Print the document.• Delete the document.

Revise Small Text Document

• Open a two-page document for revision.• Move one paragraph.• Delete one paragraph.• Insert one paragraph.• Save the altered document.• Send the document to three users.

Enter/Exit Office

• Enter the office software environment.• Exit the office software environment.

Logon/Logoff System

• Log off from the system.• Log back onto the system and enter the office environment.


Workload DescriptionPACE is a synthetic VSE batch workload consisting of 7 unique jobs representingthe commercial environment. This set of jobs is replicated 16 times, producingthe DYNAPACE workload. The first 8 copies run in 8 static partitions and another8 copies run in 4 dynamic classes, each configured with a maximum of 2partitions. The 7 jobs are:

YnDL/1YnSORTYnCOBOLYnBILLYnSTOCKYnPAYYnFORT

The programs, data, and work space for the jobs are all maintained by VSAM onseparate volumes. DYNAPACE has about a 2:1 read/write ratio.

Measurement MethodologyThe VSE system is configured with the full complement of 12 static partitions(BG, and F1 through FB). F4 through FB are the partitions used to run 8 copiesof PACE. Four dynamic classes, each with 2 partition assignments, run another8 copies of PACE.

The partitions are configured identically except for the job classes. The jobs andthe partition job classes are configured so that the jobs are equally distributed



over the partitions and so that, at any one time, the jobs currently running are amixed representation of the 7 jobs.

When the workload is ready to run, the following preparatory steps are taken:

• CICS*/ICCF is active but idle

• VTAM is active but idle

• The LST queue is emptied (PDELETE LST,ALL)

• The accounting file is deleted (J DEL)

Once performance data gathering is initiated for the system (hardwareinstrumentation, CP MONITOR, and RTM), the workload is started by releasingall of the batch jobs into the partitions simultaneously using the POWERcommand, PRELEASE RDR,*Y.

As the workload nears completion, various partitions will finish the work allottedto them. The finish time for both the first and last partitions is noted. ETR iscalculated as the total elapsed time from the moment the jobs are released untilthe last partition is waiting for work.

At workload completion, the ITR is calculated by dividing the number of batchjobs by average processor busy time. The processor busy time is calculated aselapsed (wall clock) time multiplied by average processor busy percent dividedby 100. The ITR value is multiplied by 60 to represent jobs per CPU busy minute.


Configuration Details

Appendix B. Configuration Details

Saved SegmentsCMS allows the use of saved segments for shared code. Using saved segmentscan greatly improve performance by reducing end users′ working set sizes andthereby decreasing paging. The CMS and OV/VM environments in this reportused the following saved segments:

CMS Contains the CMS nucleus and file status tables (FSTs) for the S-and Y-disks.

CMSFILES Contains the SFS server code in the DMSDAC and DMSSAC logicalsegments.

CMSPIPES Contain CMSPIPES code in the PIPES logical segment.

CMSINST Contains the execs-in-storage segment.

CMSVMLIB Contains the following logical segments:

• VMLIB contains the CSL code.

• DMSRTSEG contains the REXX runtime library.

HELP Contains FSTs for the HELP disk.

GOODSEG Contains FSTs for the C-disk. The C-disk is in the CMS searchorder used by the minidisk version of the FS8F workload.

FORTRAN This segment space has two members: DSSVFORT for theFORTRAN compiler and FTNLIB20 for the library compositemodules.

DSMSEG4B Contains DCF (Document Composition Facility) code.

OFSSEG Contains OV/VM user functions

EPUYSSEG Contains OV/VM mailbox manager code

DW370210 Contains the DW370 module

DDDCL210 Contains the DW370 compiled CLISTS

DW362 Contains FSTs for the DW/370 362 disk

ADM399 Contains FSTs for the OV/VM 399 disk

GCSXA Contains the GCS nucleus.

VTAMXA Contains the VTAM code.

Server Options: SFS DMSPARMSThis section lists the start-up parameter settings used by each of the SFSservers. The start-up parameters determine the operational characteristics ofthe file pool server. The SFS servers used the following DMSPARMS file:


Configuration Details

ADMIN MAINT U3 OPERATOR MARKNOBACKUPFULLDUMPFILEPOOLID fp_nameNOFORMATACCOUNTMSGSSAVESEGID CMSFILES

USERS nnnn

For all SFS measurements, the SAVESEGID is specified to identify the segmentcontaining the file pool server runnable code. USERS was set equal to thenumber of logged on users that were connected to the SFS file pool serverduring the measurement. The USERS parameter is used by the SFS server toconfigure itself with the appropriate number of user agents and buffers.

Server Options: CRR DMSPARMSThis section lists the start-up parameter settings used by the CRR recoveryserver. The start-up parameters determine the operational characteristics of theCRR recovery server. The CRR server uses the following DMSPARMS file:

ADMIN MAINT U3 OPERATOR MARKNOBACKUPFULLDUMPFILEPOOLID fp_nameNOFORMATACCOUNTMSGSSAVESEGID CMSFILESCRRLUNAME lu_name

For more information on the SFS and CRR tuning parameters, see the CMS FilePool Planning, Administration, and Operation manual or the VM/ESA:Performance manual.

Appendix B. Configuration Details 93

Glossary of Performance Terms


Many of the performance terms use postscripts toreflect the sources of the data described in thisdocument. In all cases, the terms presented here aretaken directly as written in the text to allow them tobe found quickly. Often there will be multipledefinitions of the same data field, differing only in thepostscript. This allows the precise definition of eachdata field in terms of its origins. The postscripts are:

< n o n e > . No postscript indicates that the data areobtained from the VM/ESA Realtime Monitor.

(C). Denotes data from the VSE console timestampsor from the CICSPARS reports (CICS transactionperformance data).

(H). Denotes data from the internal processorinstrumentation tools.

(I). Denotes data from the CP INDICATE USERcommand.

(Q). Denotes data from the SFS QUERY FILEPOOLSTATUS command.

(QT). Denotes data from the CP QUERY TIMEcommand.

Server . Indicates that the data are for specific virtualmachines, (for example SFS, CRR, or VTAM/VSCS). Ifthere is more than one virtual machine of the sametype, these data fields are for all the virtual machinesof that type.

(S). Identifies OS/2 data from the licensed program,System Performance Monitor 2 (SPM2).

(T). Identifies data from the licensed program,Teleprocessing Network Simulator (TPNS).

(V). Denotes data from the licensed program VMPerformance Reporting Facility.

The formulas used to derive the various statistics arealso shown here. If a term in a formula is in italics,such as Total_Transmits, then a description of how itsvalue is derived is provided underneath the formula.If a term is not in italics, such as SFSTIME, then it hasan entry in the glossary describing its derivation.

Absolute Share . An ABSOLUTE share allocates to avirtual machine an absolute percentage of all theavailable system resources.

Agent . The unit of sub-dispatching within a CRR orSFS file pool server.

Agents Held . The average number of agents that arein a Logical Unit of Work (LUW). This is calculated by:

11000

× ∑f ∈ f i lepools

A g e n t _H o l d i n g _T ime fSFSTIME f

Agent_Holding_T ime is from the QUERY FILEPOOL STATUS

command.

Agents In Call . The average number of agents thatare currently processing SFS server requests. This iscalculated by:

11000


Fi lpool_Reques t _Serv ice _T ime fSFSTIME f

Fi lepool_Request_Service_T ime is from the QUERY FILEPOOL

STATUS command.

Avg Filepool Request Time (ms) . The average time ittakes for a request to the SFS file pool servermachine to complete. This is calculated by:

Agents In Cal l

∑f ∈ f i lepools

Tota l _Fi lepool_Reques ts fSFSTIME f

Total_Fi lepool_Requests is from the QUERY FILEPOOL STATUS

command.

AVG FIRST (T) . The average response time inseconds for the first reply that returns to the screen.For non-fullscreen commands this is the commandreflect on the screen. This is calculated by:

1

ETR (T)× ∑

t ∈ TPNS machines

Fi rs t _Response t × Total_T ransmi t s tTPNS_T ime t

First_Response is the average first response given in the RSPRPT

section of the TPNS reports. Total_Transmits is the total TPNS

transmits and TPNS_Time is the run interval log time found in the

Summary of Elapsed Time and Times Executed section of the TPNS

reports.

AVG LAST (T) . The average response time inseconds for the last response to the screen. If thereis more than one TPNS this is calculated by:

1

ETR (T)× ∑

t ∈ TPNS machines

Last_Response t × Total_T ransmi t s tTPNS_T ime t

Last_Response is the average last response given in the RSPRPT

section of the TPNS reports. Total_Transmits is the total TPNS

transmits and TPNS_Time is the run interval log time found in the

Summary of Elapsed Time and Times Executed section of the TPNS

reports.



AVG Lock Wait Time (ms) . The average time it takesfor an SFS lock conflict to be resolved. This iscalculated by:


Lock_Wai t _T ime fSFSTIME f


Tota l _Lock_Con f l i c t s fSFSTIME f

Lock_Wait_T ime and Total_Lock_Confl icts are both from the QUERY

FILEPOOL STATUS command.

AVG LUW Time (ms) . The average duration of anSFS logical unit of work. This is calculated by:


A g e n t _H o l d i n g _T ime fSFSTIME f


B e g i n _LUWs fSFSTIME f

Agent_Holding_T ime and Begin_LUWs are both from the QUERY


AVG RESP (C) . The average response time inseconds for a VSE CICS transaction. This iscalculated by:

1

ETR (C)× ∑

t ∈ CICSPARS f i les

Last_Response t × Total_T ransmi t s tCICS_T ime t

Last_Response is taken from the AVG TASK RESPONSE TIME line

and Total_Transmits is from the TOTAL TASKS SELECTED line the

CICSPARS reports. CICS_Time is the run interval time, which is 900

seconds for al l measurements.

AVG THINK (T) . Average think time in seconds. Theaverage think time determined by TPNS for all users.This is calculated by:

1

ETR (T)× ∑

t ∈ TPNS machines

Th ink _T ime t × Total_T ransmi t s tTPNS_T ime t

Think_T ime is the average think time given in the RSPRPT section of

the TPNS reports. Total_Transmits is the total TPNS transmits and

TPNS_Time is the run interval log time found in the Summary of

Elapsed Time and Times Executed section of the TPNS reports.

Bactrian . A two-humped curve used to represent thethink times for both active users and users who arelogged on but inactive. The distribution includesthose long think times that occur when a user is notactively issuing commands. Actual user data werecollected and used as input to the creation of theBactrian distribution.

BFS . Byte File System

BIO Request Time (ms) . Average time required toprocess a block I/O request in milliseconds. This iscalculated by:


Tota l _B IO _Reques t _T ime fSFSTIME f


Tota l _B IO _Reques ts fSFSTIME f

Total_BIO_Request_T ime and Total_BIO_Requests are both from the

QUERY FILEPOOL STATUS command.

Blocking Factor (Blocks/BIO) . The average numberof blocks read or written per Block I/O Request. Thisis calculated by:


Tota l _DASD _B lock _Trans fe rs fSFSTIME f


Tota l _B IO _Reques ts fSFSTIME f

Total_DASD_Block_Transfers and Total_BIO_Requests are both from

the QUERY FILEPOOL STATUS command.

Chaining Factor (Blocks/IO) . The average number ofblocks read or written per I/O request. This iscalculated by:


Tota l _DASD _B lock _Trans fe rs fSFSTIME f


Tota l _IO_Reques ts fSFSTIME f

Total_DASD_Block_Transfers and Total_IO_Requests are both from

the QUERY FILEPOOL STATUS command.

Checkpoint . 1) In an SFS file pool server, theperiodic processing that records a consistent state ofthe file pool on DASD. 2) In a CRR recovery server,the process used to maintain the log disks. All activesyncpoint information is written to the logs.

Checkpoint Duration . The average time, in seconds,required to process an SFS checkpoint. This iscalculated by:

11000

×


Checkpo in t _T ime f


Checkpo in ts _Taken f

Checkpoint_T ime and Checkpoints_Taken are from the QUERY


Checkpoint Utilization . The percentage of time anSFS file pool server spends performing checkpoints.This is calculated by:

110


Checkpo in t _T ime fSFSTIME f

Checkpoint_T ime is from the QUERY FILEPOOL STATUS command.

Glossary of Performance Terms 95


Checkpoints Taken (delta) . The number ofcheckpoints taken by all file pools on the system.This is calculated by:


Checkpo in ts _Taken f

Checkpoints_Taken is from the QUERY FILEPOOL STATUS command.

CMS BLOCKSIZE . The block size, in bytes, of theusers ′ CMS minidisks.

Command . In the context of reporting performanceresults, any user interaction with the system beingmeasured.

CP/CMD . For the FS7F, FS8F, and VSECICSworkloads, this is the average amount of CPprocessor time used per command in mill iseconds.For the PACE workload, this is the average CPprocessor time per job in seconds. This is calculatedby:

For the FS7F, FS8F, and VSECICS workloads:

10 ×(TOTAL − TOTAL EMUL)

ETR (T)

For the PACE workload:

PBT /CMD − EMUL/CMD

CP/CMD (H). See CP/CMD. This is the hardwarebased measure. This is calculated by:

For 9221 processors:


CP_CPU_PCT × TOTAL (H)

10 × ETR (T)


6000 ×CP_CPU_PCT × TOTAL (H)

ETR (H)

CP_CPU_PCT is taken from the Host CPU Busy line in the CPU

Busy/MIPs section of the RE0 report.

For all workloads running on 9121 and 9021 processors:

PBT /CMD (H) − EMUL/CMD (H)

CP CPU/CMD (V) Server . CP processor time, inmilliseconds, run in the designated server machineper command. This is calculated by:

( 1

V_T ime × ETR (T)) × ∑

s ∈ server class

(TCPU s − VCPU s)

TCPU is Total CPU busy seconds, VCPU is Virtual CPU seconds, and

V_Time is the VMPRF time interval obtained from the Resource

Util ization by User Class section of the VMPRF report.

CPU PCT BUSY (V) . CPU Percent Busy. Thepercentage of total available processor time used bythe designated virtual machine. Total availableprocessor time is the sum of online time for allprocessors and represents total processor capacity(not processor usage).

This is the from the CPU Pct field in the VMPRF

USER_RESOURCE_USER report.

CPU SECONDS (V). Total CPU time, in seconds, usedby a given virtual machine. This is the Total CPUSeconds column in VMPRF′s USER_RESOURCE_UTILreport.

CPU UTIL (V) . The percentage of time a given virtualmachine spends using the CPU. This is Total CPUSeconds column for that virtual machine in VMPRF ′sUSER_RESOURCE_UTIL report divided by run elapsedtime.

DASD IO/CMD (V) . The number of real SSCH orRSCH instructions issued to DASD, per job, used bythe VSE guest in a PACE measurement. This iscalculated by:

60 × DASD IO RATE (V)

ETR (H)

DASD IO RATE (V) . The number of real SSCH orRSCH instructions per second that are issued toDASD on behalf of a given virtual machine. This isthe DASD Rate While Logged column in VMPRF′sUSER_RESOURCE_UTIL report.

For PACE measurements, the number of real SSCH orRSCH instructions per second issued to DASD onbehalf of the VSE guest. This is calculated by:

DASD IO TOTAL (V)

V_T ime

V_Time is taken from the time stamps at the beginning of the VMPRF

DASD Activity Ordered by Activity report.

DASD IO TOTAL (V) . The number of real SSCH orRSCH instructions issued to DASD used by the VSEguest in a PACE measurement. This is calculated by:

∑d ∈ VSE Guest DASD

Tota l d

Total is taken from the Count column in the VMPRF DASD Activity

Ordered by Activity report for the individual DASD volumes used by

the VSE guest.

DASD PAGE RATE (V) . The number of DASD pagereads per second plus DASD page writes per secondthat occur in a given virtual machine. This is theDASD Read + Write column in VMPRF′sUSER_RESOURCE_UTIL report.

DASD RESP TIME (V) . Average DASD response timein milliseconds. This includes DASD service time plus(except for page and spool volumes) any time the I/Orequest is queued in the host until the requesteddevice becomes available.

This is taken from the DASD Resp Time field in the VMPRF

SYSTEM_SUMMARY_BY_TIME report.



DCE. Distributed Computing Environment. Anindustry standard for implementing distributedcomputing.

Deadlocks (delta) . The total number of SFS file pooldeadlocks that occurred during the measurementinterval summed over all production fi le pools. Adeadlock occurs when two users each request aresource that the other currently owns. This iscalculated by:


Dead locks f

Deadlocks is from the QUERY FILEPOOL STATUS command.

DIAGNOSE . An instruction that is used to request CPservices by a virtual machine. This instruction causesa SIE interception and returns control to CP.

DIAG 04/CMD . The number of DIAGNOSE code X04instructions used per command. DIAGNOSE codeX04 is the privilege class C and E CP function call toexamine real storage. This is a product-sensitiveprogramming interface. This is calculated by:

DIAG_04

RTM_Time × ETR (T)

DIAG_04 is taken from the TOTALCNT column on the RTM PRIVOPS

screen. RTM_Time is the total RTM time interval.

DIAG 08/CMD . The number of DIAGNOSE code X08instructions used per command. DIAGNOSE codeX08 is the CP function call to issue CP commandsfrom an application. This is calculated by:

DIAG_08

RTM_Time × ETR (T)



DIAG 0C/CMD . The number of DIAGNOSE codeX0C instructions used per command. DIAGNOSEcode X0C is the CP function call to obtain the timeof day, virtual CPU time used by the virtual machine,and total CPU time used by the virtual machine. Thisis calculated by:

DIAG_0C

RTM_Time × ETR (T)

DIAG_0C is taken from the TOTALCNT column on the RTM PRIVOPS


DIAG 10/CMD . The number of DIAGNOSE code X10instructions used per command. DIAGNOSE codeX10 is the CP function call to release pages ofvirtual storage. This is calculated by:

DIAG_10

RTM_Time × ETR (T)



DIAG 14/CMD . The number of DIAGNOSE code X14instructions used per command. DIAGNOSE codeX14 is the CP function call to perform virtual spoolI/O. This is calculated by:

DIAG_14

RTM_Time × ETR (T)



DIAG 58/CMD . The number of DIAGNOSE code X58instructions used per command. DIAGNOSE codeX58 is the CP function call that enables a virtualmachine to communicate with 3270 virtual consoles.This is calculated by:

DIAG_58

RTM_Time × ETR (T)



DIAG 7C/CMD . The number of DIAGNOSE codeX7C instructions used per command. DIAGNOSEcode X7C, know as the logical device supportfacility, is the CP function call that enables a virtualmachine to communicate with logical 3270 terminals.It is used by the TCP/IP VM Telnet implementation.This is calculated by:

DIAG_7C

RTM_Time × ETR (T)

DIAG_7C is taken from the TOTALCNT column on the RTM PRIVOPS


DIAG 98/CMD . The number of DIAGNOSE code X98instructions used per command. This allows aspecified virtual machine to lock and unlock virtualpages and to run its own channel program. This iscalculated by:

DIAG_98

RTM_Time × ETR (T)



DIAG 98/CMD (V) VTAM Servers . See DIAG 98/CMDfor a description of this instruction. This representsthe sum of all DIAGNOSE code X98 instructions percommand for all VTAM and VSCS servers. This iscalculated by:

DIAG_98_V T A M + DIAG_98_VSCS

ETR (T)

DIAG_98_VTAM and DIAG_98_VSCS are taken from the VMPRF Virtual

Machine Communication by User Class report for the VTAM and VSCS

server classes respectively.

DIAG A4/CMD . The number of DIAGNOSE codeXA4 instructions used per command. DIAGNOSEcode XA4 is the CP function call that supportssynchronous I/O to supported DASD. This iscalculated by:

DIAG_A4

RTM_Time × ETR (T)



DIAG_A4 is taken from the TOTALCNT column on the RTM PRIVOPS


DIAG A8/CMD . The number of DIAGNOSE codeXA8 instructions used per command. DIAGNOSEcode XA8 is the CP function call that supportssynchronous general I/O to fully supported devices.This is calculated by:

DIAG_A8

RTM_Time × ETR (T)

DIAG_A8 is taken from the TOTALCNT column on the RTM PRIVOPS


DIAG 214/CMD . The number of DIAGNOSE codeX214 instructions used per command. DIAGNOSEcode X214 is used by the Pending Page Releasefunction. This is calculated by:

DIAG_214

RTM_Time × ETR (T)



DIAG 268/CMD . The number of DIAGNOSE codeX268 instructions used per command. DIAGNOSEcode X268 is used by the CMS370AC function. Thisis calculated by:

DIAG_268

RTM_Time × ETR (T)



DIAG 270/CMD . The number of DIAGNOSE codeX270 instructions used per command. DIAGNOSEcode X270 is the CP function call to obtain the timeof day, virtual CPU time used by the virtual machine,and total CPU time used by the virtual machine. Itsoutput is the same as DIAGNOSE code X0C with twoadditional fields that provide the date as mm/dd/yyyyand yyyy-mm-dd. This diagnose interface was addedin VM/ESA 2.2.0 as part of the year 2000 support.This is calculated by:

DIAG_270

RTM_Time × ETR (T)



DIAG/CMD . The total number of DIAGNOSEinstructions used per command or job. This iscalculated by:


1

(ETR (T) × RTM_T ime )× ∑

x ∈ DIAGNOSE

TOTALCNT x


60

(ETR (H) × RTM_T ime )× ∑

x ∈ DIAGNOSE

TOTALCNT x

TOTALCNT is the count for the individual DIAGNOSE codes taken over

the total RTM time interval on the RTM PRIVOPS Screen. RTM_Timeis the total RTM time interval taken from the RTM PRIVOPS screen.

DISPATCH LIST . The average over time of thenumber of virtual machines (including loading virtualmachines) in any of the dispatch list queues (Q0, Q1,Q2 and Q3).

1N u m _Entr ies

× ∑t ∈ SCLOG entr ies

Q0t + Q0Lt + Q1t + Q1Lt + Q2t + Q2Lt + Q3t + Q3Lt

Q0t, Q0Lt .. are from the Q0CT, Q0L ... columns in the RTM SCLOG

screen. Num_Entries is the total number of entries in the RTM SCLOG

screen.

DPA . Dynamic Paging Area. The area of realstorage used by CP to hold virtual machine pages,pageable CP modules and control blocks.

EDF. Enhanced Disk Format. This refers to the CMSminidisk file system.

Elapsed Time (C) . The total time, in seconds,required to execute the PACE batch workload.

This is calculated using the timestamps that appear on the console of

the VSE/ESA guest virtual machine. The time the first job started is

subtracted from the time the last job ended.

ELIGIBLE LIST . The average over time of the numberof virtual machines (including loading virtualmachines) in any of the eligible list queues (E0, E1, E2and E3).

1N u m _Entr ies

× ∑t ∈ SCLOG entr ies

E0t + E0L t + E1t + E1L t + E2t + E2L t + E3t + E3L t

E0t, E0Lt .. are from the E0CT, E0L ... columns in the RTM SCLOG

screen. Num_Entries is the total number of entries in the RTM SCLOG

screen.

EMUL ITR . Emulation Internal Throughput Rate. Theaverage number of transactions completed persecond of emulation time.

This is from the EM_ITR field under TOTALITR of the RTM

TRANSACT screen.

EMUL/CMD . For the FS7F, FS8F, and VSECICSworkloads, this is the amount of processor time spentin emulation mode per command in mill iseconds. Forthe PACE workload, this is the emulation processortime per job in seconds.

For the FS7F, FS8F, and VSECICS workloads, this is calculated by:

10 × TOTAL EMUL

ETR (T)

For the PACE workload, this is calculated by:

6000 × TOTAL EMUL

ETR (H)



EMUL/CMD (H) . See EMUL/CMD. This is thehardware based measurement.

For the FS7F, FS8F, and VSECICS workloads, this is calculated by:

10 × TOTAL EMUL (H)

ETR (T)

For the PACE workload, this is calculated by:

6000 × TOTAL EMUL (H)

ETR (H)

ETR. External Throughput Rate. The number ofcommands completed per second, computed by RTM.

This is found in the NSEC column for ALL_TRANS for the total RTM

interval t ime on the RTM Transaction screen.

ETR (C). See ETR. The external throughput rate forthe VSE guest measurements. For the PACE workloads, it is calculated by:

60 × Jobs

Elapsed Time (C)

Jobs is the number of jobs run in the workload. The values of Jobsare 28, 42, 56, and 112 for the PACEX4, PACEX6, PACEX8, and

DYNAPACE workloads respectively.

For the VSECICS workload, it is calculated by:

1CICS_T ime

× ∑t ∈ CICSPARSf i les

Tota l _T ransmi t s t

Total_Transmits is from the TOTAL TASKS SELECTED line in the

CICSPARS reports. CICS_Time is the run interval time, which is 900

seconds for al l measurements.

ETR (T). See ETR. TPNS-based calculation of ETR. Itis calculated by:

∑t ∈ TPNS machines

Tota l _T ransmi t s tTPNS_T ime t

Total_Transmits is found in the Summary of Elapsed Time and Times

Executed section of TPNS report (TOTALS for XMITS by TPNS).

TPNS_Time is the last time in requested (reduction) period minus the

first t ime in requested (reduction) period. These times follow the

Summary of Elapsed Time in the TPNS report.

ETR RATIO . This is the ratio of the RTM-based ETRcalculation and the TPNS-based ETR calculation. Thisis calculated by:

ETR

ETR (T)

Expanded Storage . An optional integrated high-speedstorage facility, available on certain processors, thatallows for the rapid transfer of 4KB blocks betweenitself and real storage.

Exp. Storage . See expanded storage.

External Response Time . The average responsetime, in seconds, for the last response to the screen.See AVG LAST (T).

FAST CLR/CMD . The number of fast path clears ofreal storage per command or job. This includes V=Rand regular guests. This is calculated by:


Fast_Clear _Sec

ETR (T)


60 ×Fast_Clear _Sec

ETR (H)

Fast_Clear_Sec is taken from the NSEC column for the total RTM time

interval for the FAST_CLR entry on the RTM SYSTEM screen.

FCON/ESA . FCON/ESA is a program that is availablefrom IBM that provides performance monitoringcapabilities with system console operation in fullscreen mode. FCON/ESA can provide an immediateview of system performance or post process its ownhistory files or VM/ESA monitor data for selecteddata. Threshold monitoring and user loop detection isprovided. FCON/ESA also has the ability to monitorremote systems.

File Pool . In SFS, a collection of minidisks managedby a server machine.

FP REQ/CMD (Q). Total file pool requests percommand. This is calculated by:



Total_Fi lepool_Requests is from the QUERY FILEPOOL STATUS

command.

FREE TOTL/CMD . The number of requests for freestorage per command or job. This includes V=R andregular guests. This is calculated by:


Free_Tota l _Sec

ETR (T)


60 ×Free_Tota l _Sec

ETR (H)

Free_Total_Sec is taken from the NSEC column for the total RTM time

interval on the RTM SYSTEM screen.

FREE UTIL . The proportion of the amount ofavailable free storage actually used. This iscalculated by:

Free_Size

FREEPGS × 4096

Free_Size is found in the FREE column for the total RTM time interval

(<-..) on the RTM SYSTEM screen.

FREEPGS. The total number of pages used for FREEstorage (CP control blocks).

This is found in the FPGS column for the total RTM time interval

(<-..) on the RTM SYSTEM screen.



FST. File Status Table. The CMS control block thatcontains information about a file belonging to aminidisk or SFS directory.

GB . Gigabytes. 1024 megabytes.

GUEST SETTING. This field represents the type ofVSE guest virtual machine in a PACE measurement.This f ields possible values are V=V, V=F or V=R.

GUESTWT/CMD. The number of entries into guestenabled wait state per job. This is calculated by:

60 × GUESTWT/SEC

ETR (H)

GUESTWT/SEC. The number of entries into guestenabled wait state per second.

This field is taken from the NSEC column for the RTM total count

since last reset, for the GUESTWT field in the RTM SYSTEM screen.

Hardware Instrumentation . See ProcessorInstrumentation

HT5. One of the CMS-intensive workloads used in theLarge Systems Performance Reference (LSPR) toevaluate relative processor performance.

IML MODE . This is the hardware IML mode used inVSE guest measurements. The possible values forthis field are 370, ESA, or LPAR.

Instruction Path Length . The number of machineinstructions used to run a given command, function orpiece of code.

Internal Response Time . The response time as seenby CP. This does not include line or terminal delays.

IO TIME/CMD (Q). Total elapsed time in secondsspent doing SFS file I/Os per command. This iscalculated by:

1

(1000 × ETR (T))× ∑

(f ∈ f i lepools)

Tota l _B IO _Reques t _T ime fSFSTIME f

Total_BIO_Request_T ime is from the QUERY FILEPOOL STATUS

command.

IO/CMD (Q). SFS file I/Os per command. This iscalculated by:

1

ETR (T)× ∑

f ∈ f i lepools

Tota l _IO_Reques ts fSFSTIME f

Total_IO_Requests is from the QUERY FILEPOOL STATUS command.

ISFC. Inter-System Facility for Communications

ITR. Internal Throughput Rate. This is the number ofunits of work accomplished per unit of processor busytime in an nonconstrained environment. For theFS7F, FS8F, and VSECICS workloads this is

represented as commands per processor second. Forthe PACE workload, this is represented as jobs perprocessor minute. This is calculated by:

For the FS7F, FS8F, and VSECICS workloads, this is found from the

TOTALITR for SYS_ITR on the RTM TRANSACT screen.


100 × ETR (H)

UTIL/PROC

ITR (H). See ITR. This is the hardware basedmeasure. In this case, ITR is measured in externalcommands per unit of processor busy time. For theFS7F, FS8F, and VSECICS workloads this isrepresented as commands per processor second,while for the PACE workload this is represented injobs per processor minute. This is calculated by:


100 × ETR (T)

UTIL/PROC (H)

For the PACE workloads:

6000 × Jobs

Elapsed t ime (H) × UTIL/PROC (H)

Jobs is the number of jobs run in the workload. The values of Jobsare 28, 42, 56, and 112 for the PACEX4, PACEX6, PACEX8, and

DYNAPACE workloads respectively.

ITR (V). See ITR. This is the VMPRF-based measure.ITR is measured in external commands per unit ofprocessor busy time. This is calculated by:

100 × ETR (T)

UTIL/PROC (V)

ITRR. Internal Throughput Rate Ratio. This is theRTM based ITR normalized to a specific run. This iscalculated by:

ITRITR1

ITR1 is the ITR of the first run in a given table.

ITRR (H). See ITRR. This is the ITR (H) normalizedto a specific run. This is calculated by:

ITR (H)

ITR (H)1

ITR (H)1 is the ITR (H) of the first run in a given table.

ITRR (V). See ITRR. This is the ITR (V) normalizedto a specific run. This is calculated by:

ITR (V)

ITR (V)1

ITR (V)1 is the ITR (V) of the first run in a given table.

IUCV. Inter-User Communication Vehicle. A VMgeneralized CP interface that helps the transfer of



messages either among virtual machines or betweenCP and a virtual machine.

I/O Req/sec (S) . I/O requests per second. This isAccess Rate, taken from the SPM/2 DISK report,summed over all the Physical IDs that the S/390workload is using.

k . Multiple of 1000.

Kb . Kilobits. One kilobit is 1024 bits.

KB . Kilobytes. One kilobyte is 1024 bytes.

LUW Rollbacks (delta) . The total number of SFSlogical units of work that were backed out during themeasurement interval, summed over all productionfile pools. This is calculated by:


LUW _Rol lbacks f

LUW_Rol lbacks is from the QUERY FILEPOOL STATUS command.

MASTER EMUL . Total emulation state utilization forthe master processor. For uniprocessors this is thesame as TOTAL EMUL and is generally not shown.this is the same as

This is taken from the %EM column for the first processor l isted in

the LOGICAL CPU STATISTICS section of the RTM CPU screen. The

total RTM interval t ime value is used (<-..) .

MASTER EMUL (H) . Total emulation state util izationfor the master processor. For uniprocessors this isthe same as TOTAL EMUL and is generally not shown.This is the hardware based calculation.

This is taken from the %CPU column of the GUES-CPn line of the

REPORT fi le for the master processor number as shown by RTM. In

RTM, the first processor listed on the CPU screen is the master

processor.

MASTER TOTAL . Total utilization of the masterprocessor. For uniprocessor this is the same asTOTAL and is generally not shown.

This is taken from the %CPU column for the first processor l isted in

the LOGICAL CPU STATISTICS section of the RTM CPU screen. The

total RTM interval t ime value is used (<-..) .

MASTER TOTAL (H) . Total utilization of the masterprocessor. For uniprocessor this is the same asTOTAL (H) and is generally not shown. This is thehardware based calculation.

This is taken from the %CPU column of the SYST-CPn line of the

REPORT fi le for the master processor number as shown by RTM. In

RTM, the first processor listed on the CPU screen is the master

processor.

MB . Megabytes. One megabyte is 1,048,576 bytes.

MDC AVOID . The number of DASD read I/Os persecond that were avoided through the use of minidiskcaching.

For VM releases prior to VM/ESA 1.2.2, this is taken from the NSEC

column for the RTM MDC_IA field for the total RTM time interval on

the RTM SYSTEM screen.

For VM/ESA 1.2.2 and higher, this is taken from the NSEC column for

the RTM VIO_AVOID field for the total RTM time interval on the RTM

MDCACHE screen.

MDC HIT RATIO . Minidisk Cache Hit Ratio. For VMreleases prior to VM/ESA 1.2.2, the number of blocksfound in the minidisk cache for DASD read operationsdivided by the total number of blocks read that areeligible for minidisk caching.

This is from the MDHR field for the total RTM time interval (<-..) on


For VM/ESA 1.2.2 and higher, the number of I/Osavoided by minidisk caching divided by the totalnumber of virtual DASD read requests (except forpage, spool, and virtual disk in storage requests).

This is from the MDHR field for the total RTM time interval (<-..) on

the RTM MDCACHE screen.

MDC MODS. Minidisk Cache Modifications. Thenumber of times per second blocks were written inthe cache, excluding the writes that occurred as aresult of minidisk cache misses. This measure onlyapplies to VM releases prior to VM/ESA 1.2.2.

This is taken from the NSEC column for the RTM MDC_MO field for

the total RTM time interval on the RTM SYSTEM screen.

MDC READS (blks) . Minidisk Cache Reads. Thenumber of times per second blocks were found in thecache as the result of a read operation. This measureonly applies to VM releases prior to VM/ESA 1.2.2.

This is taken from the NSEC column for the RTM MDC_HT field for the

total RTM time interval on the RTM SYSTEM screen.

MDC READS (I/Os) . Minidisk Cache Reads. The totalnumber of virtual read I/Os per second that read datafrom the minidisk cache. This measure does notapply to VM releases prior to VM/ESA 1.2.2.

This is taken from the NSEC column for the RTM MDC_READS field

for the total RTM time interval on the RTM MDCACHE screen.

MDC REAL SIZE (MB) . The size, in megabytes, of theminidisk cache in real storage. This measure doesnot apply to VM releases prior to VM/ESA 1.2.2.

This is the ST_PAGES count on the RTM MDCACHE screen, divided

by 256.

MDC WRITES (blks) . Minidisk Cache Writes. Thenumber of CMS Blocks moved per second from main



storage to expanded storage. This measure onlyapplies to VM releases prior to VM/ESA 1.2.2.

This is taken from the NSEC column for the RTM MDC_PW field for

the total RTM time interval on the RTM SYSTEM screen.

MDC WRITES (I/Os) . Minidisk Cache Writes. Thetotal number of virtual write I/Os per second thatwrite data into the minidisk cache. This measuredoes not apply to VM releases prior to VM/ESA 1.2.2.

This is taken from the NSEC column for the RTM MDC_WRITS field

for the total RTM time interval on the RTM MDCACHE screen.

MDC XSTOR SIZE (MB) . The size, in megabytes, ofthe minidisk cache in expanded storage.

For VM releases prior to VM/ESA 1.2.2, this is MDNE for the total

RTM time interval (<-..) on the RTM SYSTEM screen, divided by 256.

For VM/ESA 1.2.2 and higher, this is the XST_PAGES count on the

RTM MDCACHE screen, divided by 256.

Millisecond . One one-thousandth of a second.

Minidisk Caching . Refers to a CP facility that uses aportion of storage as a read cache of DASD blocks. Itis used to help eliminate I/O bottlenecks and improvesystem response time by reducing the number ofDASD read I/Os. Prior to VM/ESA 1.2.2, the minidiskcache could only reside in expanded storage and onlyapplied to 4KB-formatted CMS minidisks accessed viadiagnose or *BLOCKIO interfaces. Minidisk cachingwas redesigned in VM/ESA 1.2.2 to remove theserestrictions. With VM/ESA 1.2.2, the minidisk cachecan reside in real and/or expanded storage and theminidisk can be in any format. In addition to thediagnose and *BLOCKIO interfaces, minidisk cachingnow also applies to DASD accesses that are doneusing SSCH, SIO, or SIOF.

Minidisk File Cache . A buffer used by CMS when afile is read or written to sequentially. When a file isread sequentially, CMS reads ahead as many blocksas will fit into the cache. When a file is writtensequentially, completed blocks are accumulated untilthe cache is filled and then are written out together.

MPG. Multiple preferred guests is a facility on aprocessor that has the Processor Resource/SystemsManager* (PR/SM*) feature installed. This facilitysupports up to 6 preferred virtual machines. One canbe V=R, the others are V=F.

ms . Millisecond.

Native . Refers to the case where an operatingsystem is run directly on the hardware as opposed tobeing run as a guest on VM.

Non-shared Storage . The portion of a virtualmachine ′s storage that is unique to that virtualmachine, (as opposed to shared storage such as a

saved segment that is shared among virtualmachines). This is usually represented in pages.

NONPAGE RIO/CMD (V) . The number of real SSCHand RSCH instructions issued per command forpurposes other than paging. This is calculated by:

RIO/CMD (V) − PAGE IO/CMD (V)

NONTRIV INT. Non-trivial Internal response time inseconds. The average response time for transactionsthat completed with more than one drop from Q1 orone or more drops from Q0, Q2, or Q3 per second.

This is from TOTALTTM for the RTM NTRIV field on the RTM

TRANSACT screen.

Non-Spool I/Os (I) . Non-spool I/Os done by a givenvirtual machine. This is calculated from INDICATEUSER data obtained before and after the activitybeing measured. The value shown is final IO - initialIO.

NPDS. No Page Data-Set. A VSE/ESA option, whenrunning on VM/ESA as a V=V guest, that eliminatespaging by VSE/ESA for improved efficiency. Al lpaging is done by VM/ESA.

NUCLEUS SIZE (V) . The resident CP nucleus size inkilobytes.

This is from the <K bytes> column on the Total Resident Nucleus

line in the VMPRF System Configuration Report.

OSA . IBM S/390 Open Systems Adapter. Anintegrated S/390 hardware feature that provides anS/390 system with direct access to Token Ring,Ethernet, and FDDI local area networks.

PAGE/CMD . The number of pages moved betweenreal storage and DASD per command or job. This iscalculated by:


READS/SEC + WRITES/SEC

ETR (T) )


60 × READS/SEC + WRITES/SEC

ETR (H)

PAGE IO RATE (V) . The number of real SSCH orRSCH instructions issued on behalf of system paging.

This is the sum of all the entries in the SSCH+RSCH column for Page

devices listed in the VMPRF DASD System Areas by Type report.

PAGE IO/CMD (V) . The number of real SSCH andRSCH instructions issued per command on behalf ofsystem paging. This is calculated by:



PAGE IO RATE (V)

ETR (T)

Path length . See Instruction Path Length

PBT/CMD . For the FS7F, FS8F, and VSECICSworkloads, this is the number of milliseconds ofprocessor activity per command. For the PACEworkload, this is the number of seconds of processoractivity per job. This is calculated by:


10 × TOTAL

ETR (T)


6000 × TOTAL

ETR (H)

PBT/CMD (H) . See PBT/CMD. This is the hardwarebased measure.


10 × TOTAL (H)

ETR (T)


6000 × TOTAL (H)

ETR (H)

PC Utilization (S) . PC processor utilization. This isProcessor % Util from the CPU section of the SPM2report.

PD4. One of the CMS-intensive workloads used inthe Large Systems Performance Reference (LSPR) toevaluate relative processor performance.

PGBLPGS . The number of system pageable pagesavailable.

This is from the PPAG field for the total RTM time interval (<-) on the

RTM SYSTEM screen.

PGBLPGS/USER . The number of system pageablepages available per user. This is calculated by:

PGBLPGSUSERS

POSIX. A set of IEEE standards that define astandard set of programming and command interfacesbased on those provided by the various UNIXimplementations.

Privileged Operation . Any instruction that must berun in supervisor state.

PRIVOP/CMD. The number of virtual machineprivileged instructions simulated per command or job.This does not include DIAGNOSE instructions. This iscalculated by:


1

(ETR (T) ) × RTM _T ime )× ∑

x ∈ pr ivops

TOTALCNT x


60

(ETR (H) × RTM_T ime )× ∑

x ∈ pr ivops

TOTALCNT x

TOTALCNT is the count for the individual privop taken over the total

RTM time interval on the RTM PRIVOPS Screen. RTM_Time is the

total RTM time interval taken from the RTM PRIVOPS screen. Note :

PRIVOPS are recorded differently in 370 and XA modes.

PRIVOPS (Privileged Operations) . See PrivilegedOperation.

Processor Instrumentation . An IBM* internal toolused to obtain hardware-related data such asprocessor util izations.

Processor Utilization . The percent of time that aprocessor is not idle.

Processors . The data field denoting the number ofprocessors that were active during a measurement.

This is from the NC field under CPU statistics on the RTM CPU

screen.

PSU. Product Service Upgrade

Production File Pool . An SFS file pool in which usersare enrolled with space. All SFS read/write activity isto production file pools.

QUICKDSP ON . When a virtual machine is assignedthis option, it bypasses the normal scheduleralgorithm and is placed on the dispatch listimmediately when it has work to do. It does notspend time in the eligible lists. QUICKDSP can bespecified either via a CP command or in the CPdirectory entry.

RAID . Redundant array of independent DASD.

RAMAC . A family of IBM storage products based onRAID technology. These include the RAMAC ArraySubsystem and the RAMAC Array DASD.

READS/SEC . The number of pages read per seconddone for system paging.

This is taken from the NSEC column for the PAGREAD field for the


Real Storage . The amount of real storage used for aparticular measurement.

Relative Share . A relative share allocates to a virtualmachine a portion of the total system resourcesminus those resources allocated to virtual machineswith an ABSOLUTE share. A virtual machine with aRELATIVE share receives access to system resources



that is proportional with respect to other virtualmachines with RELATIVE shares.

RESERVE. See SET RESERVED

RESIDENT PAGES (V) . The average number ofnonshared pages of central storage that are held by agiven virtual machine. This is the Resid StoragePages column in VMPRF′s USER_RESOURCE_UTILreport.

RFC. Request for comments. In the context of thisreport, an RFC is an online document that describes aTCP/IP standard (proposed or adopted).

RIO/CMD (V). The number of real SSCH and RSCHinstructions issued per command. This is calculatedby:


RIO RATE (V)

ETR (T)


60 × RIO RATE (V)

ETR (H)

RIO RATE (V) . The number of real SSCH and RSCHinstructions issued per second.

This is taken from the I/O Rate column for the overall average on the

VMPRF System Performance Summary by Time report; the value

reported does not include assisted I/Os.

Rollback Requests (delta) . The total number of SFSrollback requests made during a measurement. Thisis calculated by:


Ro l lback _Reques ts f

Rol lback_Requests is from the QUERY FILEPOOL STATUS command.

Rollbacks Due to Deadlock (delta) . The total numberof LUW rollbacks due to deadlock that occurred duringthe measurement interval over all production fi lepools. A rollback occurs whenever a deadlockcondition cannot be resolved by the SFS server. Thisis calculated by:


Rol lbacks _Due _to _Dead lock f

Rol lbacks_Due_to_Deadlock is from the QUERY FILEPOOL STATUS

command.

RPC. Remote Procedure Call. A client request to aservice provider located anywhere in the network.

RSU. Recommend Service Upgrade

RTM . Realtime Monitor. A licensed programrealtime monitor and diagnostic tool for performancemonitoring, analysis, and problem solving.

Run ID . An internal use only name used to identify aperformance measurement.

SAC Calls / FP Request . The average number ofcalls within the SFS server to its Storage AccessComponent (SAC) per file pool request. Inenvironments where there are multiple fi le pools, thisaverage is taken over all fi le pool servers. This iscalculated by:


Sac _Cal ls fSFSTIME f



Sac_Cal ls and Total_Fi lepool_Requests are from the QUERY


Seconds Between Checkpoints . The average numberof seconds between SFS file pool checkpoints in theaverage file pool. This is calculated by:

1


Checkpo in ts _Taken fSFSTIME f

Checkpoints_Taken is from the QUERY FILEPOOL STATUS command.

SET RESERVED (Option) . This is a CP command thatcan be used to allow a V=V virtual machine to havea specified minimum number of pages resident in realstorage. It is used to reduce paging and improveperformance for a given virtual machine.

SFSTIME. The elapsed time in seconds betweenQUERY FILEPOOL STATUS invocations for a given filepool done at the beginning and end of ameasurement.

SFS TIME/CMD (Q). Total elapsed time percommand, in seconds, required to process SFS serverrequests. This is calculated by:

1

ETR (T)× ∑

f ∈ f i lepools

Fi lepool_Reques t _Serv ice _T ime fSFSTIME f

Fi lepool_Request_Service_T ime is from the QUERY FILEPOOL

STATUS command.

SHARE . The virtual machine ′s SHARE setting. TheSET SHARE command and the SHARE directorystatement allow control of the percentage of systemresources a virtual machine receives. Theseresources include processors, real storage and pagingI/O capability. A virtual machine receives itsproportion of these resources according to its SHAREsetting. See Relative and Absolute Share.

Shared Storage . The portion of a virtual machinesstorage that is shared among other virtual machines(such as saved segments). This is usuallyrepresented in pages.



SHRPGS. The number of shared frames currentlyresident.

SIE. ESA Architecture instruction to StartInterpretive Execution. This instruction is used to runa virtual machine in emulation mode.

SIE INTCPT/CMD. The number of exits from SIEwhich are SIE interceptions per command or job. SIEis exited either by interception or interruption. Anintercept is caused by any condition that requires CPinteraction such as I/O or an instruction that has to besimulated by CP. This is calculated by:

Percen t _In te rcep t × SIE/CMD

100

Percent_Intercept is taken from the %SC field for average of all

processors for the total RTM time interval (<-..) on the RTM CPU

screen.

SIE/CMD. SIE instructions used per command or job.This is calculated by:


SIE_SEC

ETR (T)


60 ×SIE_SEC

ETR (H)

SIE_SEC is taken from the XSI field for the total for all processors for

the total RTM time interval (<-..) on the RTM CPU screen.

SPM2. System Performance Monitor 2. An IBMlicensed program that collects and reportsperformance data for an OS/2 system.

STARS . System Trace Analysis Reports. Providesvarious reports based on the analysis of instructiontrace data.

S/390 Real Storage . On an IBM PC Server 500system, the amount of real storage that is available tothe System/390 processor.

TOT CPU/CMD (V) Server . The total amount ofprocessor time, in mill iseconds, for the server virtualmachine(s). This is calculated by:

1

(V_T ime × ETR (T))× ∑

s ∈ server class

Tota l _CPU_Secs s

Total_CPU_Secs and V_Time are from the Resource Util ization by

User Class section of the VMPRF reports.

TOT INT. Total Internal Response Time in seconds.Internal response time averaged over all trivial andnon-trivial transactions.

This is the value for TOTALTTM for ALL_TRANS on the RTM

TRANSACT screen.

TOT INT ADJ . Total internal response time (TOT INT)reported by RTM, adjusted to reflect what theresponse time would have been had CP seen theactual command rate (as recorded by TPNS). This isa more accurate measure of internal response timethan TOT INT. In addition, TOT INT ADJ can bedirectly compared to external response time (AVGLAST (T)) as they are both based on the same,TPNS-based measure of command rate. This iscalculated by:

TOT INT × ETR RATIO

TOT PAGES/USER . The total number of pages thatare associated, on average, with each end uservirtual machine. This is taken from VMPRF reportUCLASS_RESOURCE UTIL and is the sum of residentstorage pages, expanded storage pages, and DASDpage slots for the ″Users″ class. This is a measure ofhow many unique pages are touched during executionof the workload by the average end user.

TOTAL . The total processor utilization for a givenmeasurement summed over all processors.

This comes from the %CPU column for al l processors for the total

RTM interval t ime (<-..) on the RTM CPU screen.

TOTAL (H) . See TOTAL. This is the hardware basedmeasurement.

For 9221 processors, this is taken from the Total CPU Busy line in the

CPU Busy/Mips section of the RE0 report.

For 9121 and 9021 processors, this is calculated by:

UTIL/PROC (H) × PROCESSORS

Total CPU (I) . Total CPU time, in seconds, used by agiven virtual machine. This is calculated fromINDICATE USER data obtained before and after theactivity being measured. The value shown is finalTTIME - initial TTIME.

Total CPU (QT) . Total CPU time, in seconds, used bya given virtual machine. This is calculated fromQUERY TIME data obtained before and after theactivity being measured. The value shown is finalTOTCPU - initial TOTCPU.

TOTAL EMUL . The total emulation state time for allusers across all online processors. This indicates thepercentage of time the processors are in emulationstate.

This comes from the %EM column for al l processors for the total RTM

interval t ime (<-..) on the RTM CPU screen.

TOTAL EMUL (H) . The total emulation state time forall users across all online processors. This indicatesthe percentage of time the processors are inemulation state. This is calculated by:



For 9221 processors, this comes from the SIE CPU Busy / Total CPU

Busy (PCT) line in the RE0 report.

For 9121 and 9021 processors, this comes from the %CPU column for

the GUES-ALL line of the REPORT file times the number of

processors.

Total Time (QT) . Elapsed time, in seconds. This iscalculated from QUERY TIME data obtained beforeand after the activity being measured. The valueshown is the final CONNECT timestamp - the initialCONNECT timestamp, converted to seconds.

TPNS. Teleprocessing Network Simulator. A licensedprogram terminal and network simulation tool thatprovides system performance and response timeinformation.

Transaction . A user/system interaction as counted byCP. For a single-user virtual machine a transactionshould roughly correspond to a command. It does notinclude network or transmission delays and mayinclude false transactions. False transactions can bethose that wait for an external event, causing them tobe counted as multiple transactions, or those thatprocess more than one command without droppingfrom queue, causing multiple transactions to becounted as one.

TRACE TABLE (V) . The size in kilobytes of the CPtrace table.

This is the value of the <K bytes> column on the Trace Table l ine in

the VMPRF System Configuration Report.

Transaction (T) . This is the interval from the time thecommand is issued until the last receive prior to thenext send. This includes clear screens as a result ofan intervening MORE... or HOLDING condition.

TRIV INT. Trivial Internal Response Time in seconds.The average response time for transactions thatcomplete with one and only one drop from Q1 and nodrops from Q0, Q2, and Q3.

This is from TOTALTTM for the TRIV field on the RTM TRANSACT

screen.

TVR. Total to Virtual Ratio. This is the ratio of totalprocessor util ization to virtual processor util ization.This is calculated by:

TOTALTOTAL EMUL

TVR (H). See TVR. Total to Virtual Ratio measuredby the hardware monitor. This is calculated by:

TOTAL (H)

TOTAL EMUL (H)

T/V Ratio . See TVR

Users . The number of virtual machines logged on tothe system during a measurement interval that areassociated with simulated end users. This includes

active and inactive virtual machines but does notinclude service machines.

UTIL/PROC . Per processor utilization. This iscalculated by:

TOTALPROCESSORS

UTIL/PROC (H) . Per processor utilization reported bythe hardware.

For 9221 processors, this is calculated by:

TOTAL (H)

PROCESSORS

For 9121 and 9021 processors:

This is taken from the %CPU column in the SYST-ALL line of the

REPORT file.

UTIL/PROC (V) . Average util ization per processorreported VMPRF.

This is taken from the CPU Pct Busy field in the VMPRF

SYSTEM_SUMMARY_BY_TIME report.

VIO RATE . The total number of all virtual I/Orequests per second for all users in the system.

This is from the ISEC field for the total RTM time interval (<-) on the

RTM SYSTEM screen.

VIO/CMD. The average number of virtual I/Orequests per command or job for all users in thesystem. This is calculated by:


VIO RATE

ETR (T) )


60 × VIO RATE

ETR (H)

Virtual CPU (I) . Virtual CPU time, in seconds, used bya given virtual machine. This is calculated fromINDICATE USER data obtained before and after theactivity being measured. The value shown is finalVTIME - initial VTIME.

Virtual CPU (QT) . Virtual CPU time, in seconds, usedby a given virtual machine. This is calculated fromQUERY TIME data obtained before and after theactivity being measured. The value shown is finalVIRTCPU - initial VIRTCPU.

VIRT CPU/CMD (V) Server . Virtual processor time, inmilliseconds, run in the designated server(s) machineper command. This is calculated by:

1

(V_T ime × ETR (T))× ∑

s ∈ server class

V i r t _CPU_Secs s

Vir t_CPU_Secs and V_Time are from the Resource Util ization by User

Class section of the VMPRF reports.



VM Mode . This field is the virtual machine setting(370, XA or ESA) of the VSE guest virtual machine inPACE and VSECICS measurements.

VM Size . This field is the virtual machine storagesize of the VSE guest virtual machine in PACE andVSECICS measurements.

VMPAF . Virtual Machine Performance AnalysisFacility. A tool used for performance analysis of VMsystems.

VMPRF. VM Performance Reporting Facility. Alicensed program that produces performance reportsand history files from VM/XA or VM/ESA monitor data.

VSCSs . The number of virtual machines runningVSCS external to VTAM during a measurementinterval.

VSE Supervisor . This field is the VSE supervisormode used in a PACE or VSECICS measurement.

VTAMs . The number of virtual machines runningVTAM during a measurement interval.

V = F . Virtual equals fixed machine. A virtualmachine that has a fixed, contiguous area of realstorage. Unlike V=R, storage does not begin at page0. For guests running V=F, CP does not page thisarea. Requires the PR/SM hardware feature to beinstalled.

V = R . Virtual equals real machine. Virtual machinethat has fixed, contiguous area of real storagestarting at page 0. CP does not page this area.

V = V . Virtual equals virtual machine. Defaultstorage processing. CP pages the storage of a V=Vmachine in and out of real storage.

WKSET (V) . The average working set size. This isthe scheduler ′s estimate of the amount of storage theaverage user will require, in pages.

This is the average of the values for WSS in the VMPRF Resource

Util ization by User report, (found in the Sum/Avg l ine).

WKSET (V) Server . Total working set of a relatedgroup of server virtual machine(s). This is calculatedby:

∑s ∈ server Logged Users

A v g _WSS s

Avg_WSS is found in the Avg WSS column in the VMPRF Resource

Util ization by User Class report for each class of server.

WRITES/SEC. The number of page writes per seconddone for system paging.

This is taken from the NSEC column for the PAWRIT field for the total

RTM time interval on the RTM SYSTEM screen.

XSTOR IN/SEC. The number of pages per secondread into main storage from expanded storage. Thisincludes fastpath and non-fastpath pages. It iscalculated by:

Fastpath_In + NonFastpath_In

Fastpath_In and NonFastpath_In are taken from the NSEC column for

the XST_PGIF and XST_PGIS fields for the total RTM time interval on


XSTOR OUT/SEC. The number of pages per secondwritten from main storage into expanded storage.

This is taken from the NSEC column for the XST_PGO field for the


XSTOR/CMD. The number of pages read into mainstorage from expanded storage and written toexpanded storage from main storage per command orjob. This is calculated by:


XSTOR IN/SEC + XSTOR OUT/SEC

ETR (T)


60 × XSTOR IN/SEC + XSTOR OUT/SEC

ETR (H)


ibm - virtual machine/ enterprise systems architecture performance report version … ·...

Documents