Virtual Machine/ Enterprise Systems Architecture ... · PEEK is often used to view the beginning of a large reader file (PEEK defaults to reading the first 200 records).With VM/ESA

Virtual Machine/Enterprise Systems Architecture

Performance ReportVersion 2 Release 4

July 6, 1999

VM Performance Group

IBM CorporationEndicott, New York

[email protected]

Copyright International Business Machines Corporation 1999. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ivProgramming Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ivTrademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vAcknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v

Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi

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

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

Changes That Affect Performance . . . . . . . . . . . . . . . . . . . . . . . . . . 3Performance Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Performance Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

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

Migration from VM/ESA 2.3.0 and TCP/IP FL 310 . . . . . . . . . . . . . . . . . . 11CMS-Intensive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

9121-742 / Minidisk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119121-480 / Minidisk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159121-480 / SFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

VSE/ESA Guest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Telnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Migration from Other VM Releases . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Additional Evaluations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47LIMITHARD Share Capping Option . . . . . . . . . . . . . . . . . . . . . . . . . . 47Reusable Server Kernel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48Tivoli ADSM Version 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Appendix A. Workloads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58CMS-Intensive (FS8F) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58VSE Guest (DYNAPACE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Appendix B. Configuration Details . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Glossary of Performance Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Copyright IBM Corp. 1999 iii

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.4.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.4.0. See the IBM Programming Announcement forVM/ESA 2.4.0 for more information about what publications are considered to beproduct documentation.

iv Copyright IBM Corp. 1999

TrademarksThe following terms are trademarks of the IBM Corporation in the United Statesor other countries or both:

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

Tivoli ADSM is a trademark of Tivoli Systems Inc. in the United States, or othercountries, or both.

Java and all Java-based trademarks and logos are trademarks or registeredtrademarks of Sun Microsystems, Inc. in the United States and/or othercountries.

UNIX is a registered trademark in the United States and/or other countrieslicensed exclusively through X/Open Company Limited.

Other company, product, and service names may be trademarks or servicemarks of others.

Acknowledgements

The following people contributed to this report:

Bill BitnerWes ErnsbergerBill Guzior

Notices v

Abstract

The VM/ESA Version 2 Release 4.0 Performance Report summarizes theperformance evaluation of VM/ESA 2.4.0, including TCP/IP Function Level 320.Measurements were obtained for CMS-intensive, VSE guest, Telnet, FTP, andNFS environments on various ES/9000 processors. Discussion covers theperformance changes in VM/ESA 2.4.0, the performance effects of migrating fromVM/ESA 2.3.0 to VM/ESA 2.4.0, the performance effects of migrating from TCP/IP310 to TCP/IP 320, and additional evaluations.

vi Copyright IBM Corp. 1999

Referenced Publications

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

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

• TCP/IP Function Level 320 Planning and Customization, SC24-5847

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.ibm.com/s390/vm/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, seehttp://www.ibm.com/s390/vm/perf/docs/

• VM/ESA Version 2 Release 3.0 Performance Report, seehttp://www.ibm.com/s390/vm/perf/docs/

Much additional VM/ESA performance information is available on the VM/ESAperformance page at http://www.ibm.com/s390/vm/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.

Copyright IBM Corp. 1999 vii

viii VM/ESA 2.4.0 Performance Report

Summary of Key Findings


This report summarizes the performance evaluation of VM/ESA Version 2Release 4.0, including TCP/IP Function Level 320. Measurements were obtainedfor the CMS-intensive, VSE guest, Telnet, FTP, and NFS 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.4.0 includes a number of performanceenhancements (page 3) and changes that affect VM/ESA performancemanagement (page 5):

• Performance Improvements

− VM/ESA

- CMS Multitasking Improvements- Improved CMS EXECs, Xedit Macros, and PIPELINE Stages- Improved SFS Locking Characteristics

− TCP/IP

- Improved NFS Performance- TCP Layer Pathlength Reductions- Improved Window Scaling- Maximum Large Envelope Size Increased- FTP Client Pathlength Reduction

• Performance Management Changes

− Improved LIMITHARD Share Capping Option− Monitor Enhancements− Effects on Accounting Data− VM Performance Products

Migration from VM/ESA 2.3.0 and TCP/IP 310

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

CMS-intensive Overall performance was similar to VM/ESA 2.3.0. The internalthroughput rate (ITR) decreased by an average 0.6% whileresponse times were equivalent (page 11).

VSE guest Performance was equivalent for both the V=R and V=Venvironments (page 22).

Benchmark measurements show the following performance results for TCP/IP FL320 relative to TCP/IP FL 310:

Telnet Performance was equivalent (page 26).

FTP Performance of the “get” cases improved while performance ofthe “put” cases was unchanged. On average, FTP getthroughput improved by 2% while total CPU usage improved by6% (page 29).

NFS Elapsed time improvements of up to 83% and processor usageimprovements of up to 87% have been measured for NFSworkloads. NFS access to BFS files improved the most. The

Copyright IBM Corp. 1999 1


performance of NFS access to minidisk, SFS, and BFS files isnow much more similar than it was with TCP/IP FL 310 (page 30).

Additional Evaluations

Measurement results indicate that the actual processor utilization observed for avirtual machine now tracks more closely to the processor utilization cap that wasrequested for it by use of the LIMITHARD option of the SET SHARE command(page 47).

Measurement results demonstrate that the Reusable Server Kernel can sustainhigh levels of throughput while retaining good response times (page 48).

Tivoli ADSM Version 3 offers substantially improved performance relative toVersion 2. For backup, throughput improvements ranging from 7% to 188%were observed, while VM processor and I/O usage improved by 17% to 66% andby 77% to 87% respectively. Restore improvements were smaller. Throughputimprovements ranged from -3% to 15%, while VM processor and I/O usageimproved by 21% to 52% and by 0% to 47% respectively (page 51).

2 VM/ESA 2.4.0 Performance Report

Performance Improvements

Changes That Affect Performance

This chapter contains descriptions of various changes to VM/ESA 2.4.0 that affectperformance. It is divided into two sections — “Performance Improvements” and“Performance Management.” This information is also available athttp://www.ibm.com/s390/vm/perf, along with corresponding information forprevious releases.

Throughout the rest of this report, references are made to these changes whendiscussing the measurement results. Those results serve to further illustratewhere these changes apply and how they may affect performance.

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

• VM/ESA

− CMS Multitasking Improvements− Improved CMS EXECs, Xedit Macros, and PIPELINE Stages− Improved SFS Locking Characteristics

• TCP/IP

− Improved NFS Performance− TCP Layer Pathlength Reductions− Improved Window Scaling− Maximum Large Envelope Size Increased− FTP Client Pathlength Reduction

CMS Multitasking ImprovementsThe pathlengths associated with the thread creation, event signalling, and Posixsignal handling CMS multitasking functions have been significantly reduced inVM/ESA 2.4.0. This improvement is especially applicable to situations thatinvolve access to byte file system (BFS) files. Examples: Java initializationprocessor usage was reduced by 10%. NFS server processor usage for readinga large BFS file decreased by 27% (see page 33).

Improved CMS EXECs, Xedit Macros, and PIPELINE StagesThe CMS Pipelines DATECONVERT stage is implemented in REXX. VM/ESA 2.3.0APAR VM61673 provided this stage in compiled form for improved performance.This improvement has now been integrated into VM/ESA 2.4.0.

PEEK is often used to view the beginning of a large reader file (PEEK defaults toreading the first 200 records). With VM/ESA 2.3.0, PEEK would read the entirecontents of a reader file into memory if it was in NETDATA (used by SENDFILE)or disk dump format. With VM/ESA 2.4.0, PEEK has been changed so that onlythe requested records are kept in memory. For large reader files in NETDATA ordisk dump format, this can result in greatly improved responsiveness andreduced requirements for virtual storage and processor time.

The SORT Xedit macro, formerly written in EXEC2, has been rewritten in REXX,compiled, and added to the CMSINST shared segment. This reduces processor,I/O, and real storage usage. The measured processor usage improvementswere usually in the 2% to 4% range.


Performance Improvements

The SDIR Xedit macro has been rewritten for improved serviceability andperformance, resulting in a measured 38% processor usage improvement. SDIRis used by the FILELIST function to sort by SFS subdirectory.

Processor usage of SENDFILE when using the UFTSYNC option has beensignificantly reduced.

The RECEIVE EXEC was added to the CMSINST saved segment, eliminatingloading time and reducing real storage requirements for CMS environments thatuse this function.

Improved SFS Locking CharacteristicsThree SFS performance APARs have been incorporated into VM/ESA 2.4.0. Theyall deal with scenarios where other SFS users appear to be locked out while aparticular task for another user is in progress. VM61547 and VM62008 deals withthe task of deleting large files. The impact is proportional to file size and is notreally noticeable for files under 512 Kb. VM62086 addresses a different scenariowhere a large number of file changes are made without a commit being issued.

Improved NFS PerformanceElapsed time improvements of up to 83% and processor usage improvements ofup to 87% have been measured for NFS workloads. These improvements resultfrom the combined effects of performance enhancements that were added to NFSthrough service and in TCP/IP Function Level 320, support for the NFS version 3protocol, and the CMS multitasking improvements that are included in VM/ESA2.4.0. NFS access to BFS and SFS files improved the most but NFS access tominidisk files also improved in some cases. See “NFS” on page 30 for details.

TCP Layer Pathlength ReductionsTwo improvements were made to the TCP layer of the protocol stack that serveto reduce the mainline pathlength for handling incoming messages. The firstone, sometimes referred to as “TCP header prediction,” optimizes theimplementation for the normal case where the incoming segments are allpresent and are received in the order sent. The other improvement is thecreation of a lookaside buffer for fast access to the TCP control block. Primarilydue to these improvements, processor usage in the TCPIP stack virtual machinedecreased by 0.5% for the Telnet measurement (see “Telnet” on page 26) andby an average of 4% for the 6 FTP measurements (see “FTP” on page 29).Large data transfers tend to experience the largest percentage improvements.

Improved Window ScalingAPAR PQ18391 to TCP/IP Function Level 310 is now included in TCP/IP FL 320.Previously, there was a hardcoded limit of 20 segments that could beoutstanding (unacknowledged) at any given time. This was a constraintwhenever the window size exceeded 20 times the maximum segment size. This20 segment limit has now been removed, allowing the full benefits of TCPwindow scaling (RFC 1323) to be realized.

Maximum Large Envelope Size IncreasedThe maximum large envelope size supported by TCP/IP VM has been increasedfrom 32768 bytes (32 Kb) to 65535 (64 Kb - 1). The TCP/IP stack machine useslarge envelopes to hold UDP datagrams and to hold IP datagram fragmentsduring reassembly when they do not fit into small (2048 bytes) envelopes. Large


Performance Management

envelope size is specified on the LARGEENVELOPEPOOLSIZE statement in thenode_name TCPIP (or PROFILE TCPIP) configuration file.

A large envelope size greater than 32 Kb may improve performance in certaincases. One example is when a key application can send datagrams that exceed32 Kb. Another example is when it is advantageous to be able to specify anMTU size that exceeds 32 Kb as might be the case, for example, for CTCdevices. TCP/IP VM requires that the MTU size (specified on the GATEWAYstatement) not exceed the large envelope size.

FTP Client Pathlength ReductionA change has been made to FTP MODULE that reduces pathlength in the VMclient virtual machine for the case of binary file transfer from a foreign host tothe VM system. This changed was observed to decrease processor usage in theclient virtual machine by 9% for binary get of a 2 Mb file and by 31% for binaryget of a 24 Kb file (see “FTP” on page 29 for details). This change isimplemented by TCP/IP FL 320 APAR PQ28148.

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

• Improved LIMITHARD Share Capping Option• Monitor Enhancements• Effects on Accounting Data• VM Performance Products

Improved LIMITHARD Share Capping OptionThe LIMITHARD option on the SET SHARE command can be used to limit thepercentage of total system processing capacity that can be consumed by a givenvirtual machine. In prior releases, the observed percentage would tend to belower than the requested percentage, especially at low total system processorutilizations. With VM/ESA 2.4.0, the LIMITHARD implementation has beenchanged so that the actual percentage tracks more closely to the requestedpercentage. See “LIMITHARD Share Capping Option” on page 47 formeasurement results and additional discussion.

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.4.0.The major changes in the CP monitor data were extended channel measurementsupport, inclusion of data for new DASD, and some miscellaneous changes.

With the addition of support for FICON channels, some processors have alsoadded the Extended Channel Path Measurement Facility. The original ChannelPath Measurement Facility is still supported and is used if the extended facility isnot available. A separate record, domain 0 record 20, is created for eachchannel when the extended facilities are available. For the new FICON channels,this new record will include channel utilization and number of bytes read andwritten over the channel for the physical channel and also from a logical viewwhen VM/ESA is running in a logical partition. Comments were changed in otherchannel utilization records to reference this new record where appropriate.

Changes That Affect Performance 5


Changes were also made in support of features provided by the IBM EnterpriseStorage Server (ESS). The ESS DASD subsystem allows for parallel accessvolumes where a single physical volume can appear as multiple volumes to aS/390 system. This allows multiple I/Os to be started to the same device inparallel. The Device Configuration (domain 1 record 6) and Vary On Device(domain 6 record 1) were changed to indicate whether the specified volume is aparallel access volume, and if so whether it is the base volume or an aliasvolume. Parallel access volumes are typically configured prior to system IPLs.However, the State Change event record (domain 6 record 20) was added torecord the dynamic creation of an alias volume.

The System Configuration Data (domain 1 record 4) was enhanced to indicatethe source for Subchannel Device Active Only time (as reported in domain 6record 3). On some processors this data is generated by the hardware, while onothers software generates it. Also, an indication of whether the Channel PathMeasurement Facility or Extended Channel Path Measurement Facility isavailable on the processor has been added to the System Configuration Datarecord.

The APPLDATA domain data contributed by the TCP/IP stack virtual machine hasalso been enhanced. The changes include the following.

• In order to record larger data transfer amounts, new fields were added to theTCB Close (type 2) and UCB Close (type 7) event records. This change wasintroduced via APAR PQ16942 to FL310 and rolled into the base for FL320.

• Support was added in FL320 to handle certain denial of service attacks.Discarded packets associated with these attacks are counted in the MIBrecord (type 0).

• The IP address for a connection was added to the TCB Open (type 1) andClose (type 2) records.

• Window scaling information was added to the TCB Close (type 2) record.

• The FL320 stack was optimized to predict TCP headers. A counter wasadded to the TCB Close (type 2) record to indicate the number of timesheaders were predicted correctly.

• The TCP/IP Pool Limit Record (type 3) now includes additional informationfor the new dynamic pools and for virtual storage usage in general for thestack machine. Similarly, the TCP/IP Pool Size Record (type 4) now includesthe new segment acknowledge pool.

Effects on Accounting DataNone of the VM/ESA 2.4.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.4.0 provided byVMPRF, RTM/ESA, FCON/ESA, and VMPAF.

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



Realtime Monitor VM/ESA 1.5.2 (RTM/ESA) will run on VM/ESA 2.4.0 with thesame support as VM/ESA 2.3.0. RTM must be recompiled using the VM/ESA2.4.0 libraries. Follow the ″REBUILD″ section of the RTM Program Directory.

FCON/ESA Version 3.1.xx will run on VM/ESA 2.4.0 with the same support as forVM/ESA 2.3.0. The next release, FCON/ESA V.3.2.00, planned to becomeavailable in the third quarter of 1999, will also include support for FICONchannels and some of the additional TCP/IP FL 320 data, in addition to otherenhancements that are not VM/ESA release dependent.

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

Changes That Affect Performance 7

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.

• 9672-R55

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

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

See the appropriate workload section in Appendix A, “Workloads” on page 58for 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 58.

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.

8 Copyright IBM Corp. 1999


• DASD: The DASD configuration used during the measurement.

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.

• 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 10.

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(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.

Measurement Information 9


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.3.0 and TCP/IP FL 310

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

CMS-IntensiveThe VM/ESA 2.4.0 performance results are similar to the corresponding VM/ESA2.3.0 results for the three measured CMS-intensive environments. ITR decreasesranging from 0.6% to 0.7% and external response time changes ranging from a2% decrease to a 6% increase were observed.

Although VM/ESA 2.4.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.

All measurements were done using the FS8F0R workload. See “CMS-Intensive(FS8F)” on page 58 for a description.

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 6 323390-2 3990-3 4 6 2 2 R3390-2 3990-2 4 6 23390-2 3990-2 4 10



Software Configuration

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

Virtual Machines:

Measurement Discussion: The following table shows that VM/ESA 2.4.0 showsslightly reduced performance relative to VM/ESA 2.3.0 for this workload andsystem configuration. External response time (AVG LAST(T)) increased by 6%,while the internal throughput rate (ITR(H)) decreased by 0.7%. DASD pagingincreased slightly due to a 2-page increase in the average working set size.

Control Unit NumberLines per

Control Unit Speed

3088 1 NA 4.5MB

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.3.0 onthe 9121-742

ReleaseRun ID

2.3.0S4AE5805

2.4.0S4BE5801 Difference %Difference

EnvironmentReal StorageExp. StorageUsersVTAMsVSCSsProcessors

1024MB1024MB

5800134

1024MB1024MB

5800134

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

0.1120.3590.2580.2570.3080.395

0.1120.3670.2600.2620.3290.419

0.0000.0080.0020.0060.0210.024

0.00%2.23%0.78%2.20%6.68%6.05%

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

26.20202.44203.46

0.995222.71

55.4787.901.0001.000

26.22205.16203.31

1.009221.20

55.8588.990.9931.007

0.022.72

-0.150.014-1.510.391.09

-0.0070.007

0.08%1.34%

-0.07%1.42%

-0.68%0.70%1.24%

-0.68%0.70%

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

17.96117.940

7.0486.635

10.91211.305

18.08318.101

7.1676.739

10.91611.362

0.1220.1610.1190.1030.0030.057

0.68%0.90%1.69%1.56%0.03%0.51%




ReleaseRun ID

2.3.0S4AE5805



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

365.42365.00

91.3691.25

222.02230.00

93.1393.0035.0637.00

1.651.59

367.64368.00

91.9192.00

221.92231.00

93.6894.0034.6736.00

1.661.59

2.223.000.560.75

-0.101.000.561.00

-0.38-1.000.010.01

0.61%0.82%0.61%0.82%

-0.04%0.43%0.60%1.08%

-1.10%-2.70%0.65%0.39%

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

2452KB650KB

78230K39.7193

177720.91

2165

2476KB650KB

80230K39.7193

177650.91

2183

24KB0KB

20K0.0

0-7

0.0018

0.98%0.00%2.56%0.00%0.00%0.00%

-0.04%0.04%0.83%

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

1236871

10.356350.300

1.722549

161210.622

8.474

1310930

11.018369.700

1.818516

164110.610

8.657

7459

0.66219.400

0.097-3329

-0.0120.183

5.99%6.77%6.39%5.54%5.61%

-6.01%1.80%

-0.11%2.16%

QueuesDISPATCH LISTELIGIBLE LIST

113.700.00

120.440.00

6.740.00

5.93%na

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

18399.039

7443.6571.935

21.40032.163.5568

28529

0.93

18369.031

7643.7581.939

21.60030.363.6566

28524

0.92

-3-0.008

200.1010.0040.200

-1.80.2-20

-5-0.01

-0.16%-0.09%2.69%2.76%0.23%0.93%

-5.69%0.25%

-0.35%0.00%

-0.95%-1.08%

Migration from VM/ESA 2.3.0 and TCP/IP FL 310 13



ReleaseRun ID

2.3.0S4AE5805



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.21423.923

1.0880.7350.1920.0241.2500.3043.4952.667

11.8510.941

54.06636.22445.125

20.19124.866

1.0130.7340.1920.0241.2490.2983.4682.673

12.7540.940

54.10536.25145.262

-0.0230.942

-0.075-0.0010.0000.000

-0.001-0.007-0.0270.0060.903

-0.0010.0390.0260.136

-0.11%3.94%

-6.93%-0.09%-0.14%0.13%

-0.07%-2.15%-0.76%0.22%7.62%

-0.09%0.07%0.07%0.30%

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

41292.86991.27251.5974

0.304

41402.89381.29251.6013

0.298

110.02390.02000.0039-0.006

0.27%0.83%1.57%0.24%

-2.08%

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)) wasequivalent, while internal throughput (ITR(H)) decreased by 0.6%. DASD pagingincreased slightly due to a 2-page increase in the average working set size.These results are similar to what was observed for the 9121-742 environment(see the previous section).

Type ofDASD

ControlUnit



3390-3 RAMAC 2 4 4 163390-2 3990-2 4 53390-2 3990-3 2 6 1 2 R3390-2 3990-3 4 5 1


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.3.0L2AE2047

2.4.0L2BE2042 Difference %Difference


256MB0MB2040

102

256MB0MB2040

102


0.1290.4280.3260.2940.2830.391

0.1330.4320.3300.2970.2850.393

0.0040.0040.0040.0030.0020.001

3.10%0.93%1.23%1.03%0.71%0.38%


26.1464.4171.400.90279.5535.9153.531.0001.000

26.1764.2771.380.90079.0735.6153.210.9940.992

0.03-0.14-0.02

-0.002-0.48-0.30-0.32

-0.006-0.008

0.11%-0.22%-0.02%-0.19%-0.61%-0.83%-0.59%-0.61%-0.83%


25.14025.211

8.8518.404

16.28916.807

25.29325.357

8.9658.406

16.32816.951

0.1530.1460.1140.0020.0390.144

0.61%0.58%1.29%0.02%0.24%0.86%


179.49180.00

89.7590.00

116.30120.00

89.3689.0051.1253.00

1.541.50

180.54181.00

90.2790.50

116.55121.00

89.9890.0051.2853.00

1.551.50

1.051.000.530.500.251.000.621.000.160.000.010.00

0.59%0.56%0.59%0.56%0.21%0.83%0.69%1.12%0.32%0.00%0.37%

-0.28%


2452KB350KB

8354139

26.5172

62450.94

1566

2476KB350KB

8554135

26.5173

62490.94

1670

24KB0KB

2-4

0.014

0.00104

0.98%0.00%2.41%

-0.01%-0.01%0.58%0.06%

-0.06%6.64%




ReleaseRun ID

2.3.0L2AE2047

2.4.0L2BE2042 Difference %Difference


256MB0MB2040

102

256MB0MB2040

102


728474

16.835202.500

2.83600

0.0008.404

740484

17.148205.100

2.87300

0.0008.588

1210

0.3122.6000.037

00

0.0000.184

1.65%2.11%1.85%1.28%1.31%

nanana

2.19%


43.200.02

43.800.00

0.60-0.02

1.38%-100.00%


6939.706

3955.5322.696

19.90040.6

0.0199

9.81187

0.93

6919.680

3985.5762.702

19.80039.8

0.0198

9.84186

0.93

-2-0.026

30.0430.006

-0.100-0.70.0-1

0.03-1

0.00

-0.29%-0.27%0.76%0.78%0.23%

-0.50%-1.75%

na-0.50%0.31%

-0.53%0.00%


13.89025.845

2.3210.7370.1920.0251.2490.9703.5032.661

11.8660.940

52.80334.32249.064

13.85626.820

2.2870.7330.1920.0241.2490.9633.4882.658

12.7640.940

53.15234.01749.565

-0.0350.975

-0.034-0.0040.0000.0000.000

-0.007-0.015-0.0030.8980.0000.348

-0.3050.502

-0.25%3.77%

-1.48%-0.53%0.08%

-1.25%0.00%

-0.69%-0.43%-0.12%7.57%

-0.03%0.66%

-0.89%1.02%


5383.86731.44732.4200

0.971

5533.87591.45542.4205

0.963

150.00860.00810.0005-0.007

2.79%0.22%0.56%0.02%

-0.75%




9121-480 / SFSWorkload: FS8FMAXR





DASD:


Communications:



Virtual Machines:

Measurement Discussion: External response time (AVG LAST(T)) improved by2%, while internal throughput (ITR(H)) decreased by 0.6%. This environment didnot experience a working set increase. The ITR decrease is the same asobserved for the 9121-480 minidisk environment (see the previous section).

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.3.0 on the9121-480

ReleaseRun ID

2.3.0L2AS1700

2.4.0L2BS1701 Difference %Difference


256MB00MB

1700102

256MB00MB

1700102


0.1260.4640.3530.3100.2510.374

0.1240.4430.3370.2970.2510.365

-0.002-0.021-0.016-0.0130.000

-0.009

-1.59%-4.53%-4.53%-4.35%0.20%

-2.41%


26.1552.4159.650.87966.8529.3844.601.0001.000

26.1852.5359.670.88066.4329.2744.520.9940.996

0.030.120.02

0.002-0.42-0.11-0.08

-0.006-0.004

0.11%0.23%0.04%0.19%

-0.63%-0.38%-0.18%-0.63%-0.38%


29.91729.84110.86110.05919.05619.782

30.10730.16410.99210.39019.11519.774

0.1900.3230.1310.3310.059

-0.008

0.63%1.08%1.21%3.29%0.31%

-0.04%


178.46178.00

89.2389.00

113.67118.00

89.0689.0051.1753.00

1.571.51

179.66180.00

89.8390.00

114.06118.00

89.6090.0051.1753.00

1.581.53

1.202.000.601.000.390.000.541.000.000.000.010.02

0.67%1.12%0.67%1.12%0.35%0.00%0.61%1.12%0.00%0.00%0.33%1.12%


2452KB350KB

8155413

32.6159

53580.91

1851

2476KB350KB

8155403

32.6162

53840.90

1822

24KB0KB

0-100.0

326

0.00-29

0.98%0.00%0.00%

-0.02%-0.02%1.89%0.49%

-0.48%-1.57%




ReleaseRun ID

2.3.0L2AS1700



256MB00MB

1700102

256MB00MB

1700102


595390

16.513154.100

2.58300

0.0008.164

616394

16.925154.600

2.59100

0.0008.278

214

0.4120.5000.007

00

0.0000.114

3.53%1.03%2.50%0.32%0.29%

nanana

1.40%


43.020.00

38.770.00

-4.250.00

-9.88%na


5929.925

3575.9853.402

17.90067.1

0.0155

15129

0.82

5909.887

3565.9663.375

18.00066.6

0.0155

15128

0.82

-2-0.037

-1-0.019-0.0260.100

-0.50.0

00

-10.00

-0.34%-0.38%-0.28%-0.32%-0.78%0.56%

-0.79%na

0.00%0.00%

-0.78%0.00%


20.68824.009

2.4840.7390.2180.0251.2501.2221.9052.486

11.3630.941

60.78841.33652.707

20.62325.012

2.5320.7400.2140.0251.2491.1871.8962.495

12.2160.942

60.96541.45653.056

-0.0651.0030.0480.001

-0.0040.000

-0.001-0.035-0.0100.0090.8540.0000.1770.1210.348

-0.32%4.18%1.95%0.16%

-1.80%0.62%

-0.08%-2.85%-0.51%0.37%7.51%0.03%0.29%0.29%0.66%


5194.09801.52742.5706

1.222

4924.08711.52682.5602

1.186

-27-0.0109-0.0006-0.0104

-0.035

-5.20%-0.27%-0.04%-0.40%-2.90%




ReleaseRun ID

2.3.0L2AS1700



256MB00MB

1700102

256MB00MB

1700102

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)

33603.45531.51811.9372

1.1531.6380.0220.031

33533.45401.52681.9272

1.1561.6350.0250.037

-7-0.00130.0087

-0.01000.003

-0.0030.0030.006

-0.21%-0.04%0.57%

-0.52%0.26%

-0.18%13.64%19.35%

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


Migration: VSE/ESA Guest

VSE/ESA GuestThis section examines the performance impact of migrating a VSE/ESA guestfrom VM/ESA 2.3.0 to VM/ESA 2.4.0. All measurements were made on a9121-320 using the DYNAPACE workload. DYNAPACE is a batch workload that ischaracterized by heavy I/O. See “VSE Guest (DYNAPACE)” on page 68 for adescription of this workload.

Measurements were obtained with the VSE/ESA system run as a V=R guest andas 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: Performance was equivalent to VM/ESA 2.3.0 for boththe V=R and V=V environments.

Type ofDASD

ControlUnit


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

3390-2 3990-03 2 13390-2 3990-02 4 10 23390-2 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 32MB/XA 100WRITER 1 CP monitor 2MB/XA 100



Table 4. VSE/ESA V = R guest migration from VM/ESA 2.3.0 on the 9121-320

ReleaseRun ID

2.3.0L1RA8PF2

2.4.0L1RB8PF2 Difference %Difference

EnvironmentIML ModeReal StorageExp. StorageVM ModeVM SizeGuest SettingVSE SupervisorProcessors

ESA256MB

0MBESA96M

V = RESA

1

ESA256MB

0MBESA96M

V = RESA

1

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

871.07.72

18.8318.821.0001.000

841.07.99

18.7518.580.9960.988

-30.00.28

-0.08-0.24

-0.004-0.012

-3.44%3.57%

-0.42%-1.25%-0.42%-1.25%

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

3.1873.1880.2910.2332.8962.955

3.2003.2290.2800.3002.9202.928

0.0130.040

-0.0100.0670.024

-0.027

0.42%1.27%

-3.55%28.74%

0.82%-0.90%

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

40.9841.0037.2438.00

1.101.08

42.6243.0038.8939.00

1.101.10

1.642.001.651.000.000.02

4.00%4.88%4.42%2.63%

-0.40%2.19%

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

2884KB200KB38532

850.61

2908KB200KB38531

790.54

24KB0KB

-1-6

-0.07

0.83%0.00%0.00%

-7.06%-11.45%

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.7772.000

15.554350840389.82

3031.568.00.0

0.030.030.010.32

1.0007.5092.000

15.018348517414.90

3115.467.80.0

0.030.030.010.35

0.000-0.2680.000

-0.536-232325.0883.90

-0.20.0

000

0.03

0.00%-3.44%0.00%

-3.44%-0.66%6.43%2.77%

-2.93%na

0.00%0.00%0.00%9.38%

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

10.675607.677

2784.0892310.794

528.821

10.473594.161

2643.1432167.377

503.098

-0.202-13.517

-140.946-143.417

-25.723

-1.89%-2.22%-5.06%-6.21%-4.86%

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



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

ReleaseRun ID

2.3.0L1VA8PF2

2.4.0L1VB8PF2 Difference %Difference


ESA160MB

0MBESA96M

V = VESA

1

ESA160MB

0MBESA96M

V = VESA

1

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

483.013.9114.6114.651.0001.000

487.013.8014.6014.531.0000.992

4.0-0.11-0.01-0.120.000

-0.008

0.83%-0.82%-0.04%-0.82%-0.04%-0.82%

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

4.1074.0971.1571.0352.9513.062

4.1094.1311.1731.0872.9363.044

0.0020.0340.0160.052

-0.014-0.018

0.04%0.83%1.38%5.03%

-0.49%-0.59%

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

95.2495.0068.4271.00

1.391.34

94.5095.0067.5370.00

1.401.36

-0.750.00

-0.89-1.000.010.02

-0.78%0.00%

-1.31%-1.41%0.53%1.43%

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

2884KB200KB38459

1070.62

2908KB200KB38452

990.59

24KB0KB

-7-8

-0.03

0.83%0.00%

-0.02%-7.48%-4.87%

PagingPAGE/CMDXSTOR/CMDFAST CLR/CMD

112.1250.000

276.000

182.6250.000

204.366

70.5000.000

-71.634

62.88%na

-25.95%

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

722.0003113.625

322.0001388.625

153866320.55

1382.39112.6

0.0442218407

0.85

718.0003122.018

313.0001360.991

149724311.93

1356.32111.7

0.0439220414

0.87

-4.0008.393

-9.000-27.634

-4142-8.63

-26.07-0.90.0-327

0.02

-0.55%0.27%

-2.80%-1.99%-2.69%-2.69%-1.89%-0.80%

na-0.68%0.92%1.72%2.35%


Migration: TCP/IP

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

ReleaseRun ID

2.3.0L1VA8PF2

2.4.0L1VB8PF2 Difference %Difference


ESA160MB

0MBESA96M

V = VESA

1

ESA160MB

0MBESA96M

V = VESA

1

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

3117.492450.594

13618.87511848.421

4019.250

3115.772444.453

13514.25011892.540

3909.045

-1.720-6.140

-104.62544.119

-110.205

-0.06%-1.36%-0.77%0.37%

-2.74%

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

TCP/IPTelnet, FTP, and NFS measurements were obtained to evaluate the performanceeffects of migrating from TCP/IP Function Level 310 to TCP/IP Function Level 320.The Telnet and FTP results showed equivalent to slightly improved performance.The NFS results showed significant performance improvements over TCP/IP FL310. The Telnet, FTP, and NFS results are summarized in the following threesections.


Migration: TCP/IP

TelnetWorkload: FS8F0R





DASD:


Communications:

16 Mbit IBM Token Ring3172-3 Interconnect Controller



Virtual Machines:

Measurement Discussion: The overall TCP/IP 320 Telnet results are essentiallyequivalent to the corresponding TCP/IP 310 results. Processor usage in theTCPIP stack virtual machine decreased by 0.5% as a result of the “TCP LayerPathlength Reductions” item discussed in “Performance Improvements” onpage 3.

Type ofDASD

ControlUnit



3390-3 RAMAC 2 4 4 163390-2 3990-2 4 53390-2 3990-3 2 6 1 2 R3390-2 3990-3 4 5 1



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

Table 6 (Page 1 of 2). Telnet migration on a 9121-480

TCP/IP ReleaseVM/ESA ReleaseRun ID

3102.4.0

L2BE1802

3202.4.0

L2BE1801Difference %Difference


256MB0MB1800

na02

256MB0MB1800

na02


0.1260.8630.2600.2350.2850.398

0.1230.8610.2570.2320.2750.387

-0.003-0.002-0.003-0.003-0.010-0.010

-2.38%-0.23%-1.15%-1.39%-3.34%-2.52%


24.4757.0863.020.90669.8831.6851.811.0001.000

24.5356.9663.040.90469.8631.5951.671.0000.997

0.06-0.120.02

-0.002-0.02-0.09-0.140.000

-0.003

0.25%-0.21%0.03%

-0.24%-0.03%-0.29%-0.27%-0.03%-0.29%


28.62128.56111.78111.10716.83917.454

28.62928.55311.79111.10416.83817.449

0.008-0.0080.010

-0.003-0.002-0.005

0.03%-0.03%0.08%

-0.03%-0.01%-0.03%


180.38180.00

90.1990.00

106.13110.00

90.7791.0043.9646.00

1.701.64

180.48180.00

90.2490.00

106.15110.00

90.8591.0043.8946.00

1.701.64

0.100.000.050.000.020.000.080.00

-0.070.000.000.00

0.06%0.00%0.06%0.00%0.02%0.00%0.09%0.00%

-0.16%0.00%0.04%0.00%


2476KB350KB

8755452

30.8178

54010.95

1126

2476KB350KB

8755485

30.8178

53690.95

1073

0KB0KB

033

0.00

-320.01-53

0.00%0.00%0.00%0.06%0.06%0.00%

-0.59%0.60%

-4.71%


Migration: TCP/IP

Table 6 (Page 2 of 2). Telnet migration on a 9121-480

TCP/IP ReleaseVM/ESA ReleaseRun ID

3102.4.0

L2BE1802

3202.4.0

L2BE1801Difference %Difference


256MB0MB1800

na02

256MB0MB1800

na02


694422

17.708175.800

2.78900

0.0008.616

698423

17.782174.500

2.76800

0.0008.629

41

0.074-1.300-0.021

00

0.0000.013

0.58%0.24%0.42%

-0.74%-0.77%

nanana

0.16%


24.110.00

24.390.00

0.280.00

1.16%na


87613.900

6199.8227.032

19.40041.4

0.0175

8.55164

0.93

87813.927

6209.8357.067

19.40041.4

0.0176

8.59165

0.93

20.028

10.0130.0340.000

-0.10.0

10.04

10.00

0.23%0.20%0.16%0.13%0.49%0.00%

-0.13%na

0.57%0.47%0.61%0.00%


1.63336.948

2.5290.7320.1920.0241.2505.1793.4892.656

12.6870.939

65.54744.57253.710

1.65737.118

2.5300.7340.1920.0241.2505.2113.4952.663

12.7780.941

65.71944.68953.869

0.0230.1700.0000.0020.0000.0000.0000.0320.0060.0060.0920.0020.1720.1170.159

1.43%0.46%0.02%0.29%0.21%0.35%0.01%0.61%0.17%0.24%0.72%0.19%0.26%0.26%0.30%

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

27005.48302.44203.0410

5.179

27005.45502.45003.0050

5.211

0-0.02800.0080

-0.03600.032

0.00%-0.51%0.33%

-1.18%0.62%



Migration: TCP/IP

FTPMeasurement Description: The measured system consisted of a 9121-480(2-way) processor running VM/ESA 2.4.0 with TCP/IP Function Level 310 or 320.This system was attached to a 16 Mbit IBM Token Ring using a 3172-3Interconnect Controller. The TCPIP server was configured to use 32 Kb TCPbuffers (DATABUFFERPOOLSIZE) and an MTU size of 4000 bytes. File transferwas to/from an RS/6000 model 250 running AIX 4.2.1 that was connected to thesame token ring.

The TCP/IP FL 320 code included APAR PQ28148. This is a change to FTPMODULE which reduces pathlength in the VM client virtual machine for binaryget cases.

The workload consisted of a number of consecutive identical FTP file transfers(get or put) initiated by a client virtual machine on the VM/ESA system. For the2 Mb files, there were 5 file transfers; for the 24 Kb files, there were 100 filetransfers. These file transfers were to/from the client virtual machine′s 191minidisk, which was enabled for minidisk caching and defined in RAMAC 2 ArraySubsystem storage.

Measurement Results: The measurement results are summarized in Table 7,Table 8, and Table 9. For each table, the absolute results are first shown,followed by the TCP/IP FL 320 to TCP/IP FL 310 ratios.

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

Run IdModeTCP/IP Release

G2M_A313ASCII

310

G2M_A2F3ASCII

320

G2M_B313Binary

310

G2M_B2F3Binary

320

Rate (Kb/sec)TCPIP CPU/Kb (msec)VM Client CPU/KbTotal CPU/Kb

428.50.2740.4160.690

432.00.2580.4150.673

454.80.2720.0790.351

454.80.2600.0720.332


1.0001.0001.0001.000

1.0080.9420.9980.975

1.0001.0001.0001.000

1.0000.9560.9110.946

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

Run IdModeTCP/IP Release

G24KA313ASCII

310

G24KA2F3ASCII

320

G24KB313Binary

310

G24KB2F3Binary

320


127.20.8851.4282.313

129.30.9141.4442.358

150.00.8891.6172.506

160.90.8931.1152.008


1.0001.0001.0001.000

1.0171.0331.0111.019

1.0001.0001.0001.000

1.0731.0040.6900.801


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: The 6 measured FTP cases showed equivalent orimproved performance relative to TCP/IP FL 310. The improvements wereconfined to the “get” cases. On average for the 4 get cases, throughputimproved by 2% while total CPU usage improved by 6%. These improvementsresulted from the combined effects of the “TCP Layer Pathlength Reductions”item (applies to gets) and the “FTP Client Pathlength Reduction” item (applies tobinary gets). See “Performance Improvements” on page 3 for a discussion ofthese performance improvements.

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

Run IdTCP/IP Release

P2M_B313310

P2M_B2F3320

P24KB313310

P24KB2F7320


496.10.4340.0640.498

489.10.4400.0660.506

315.61.0741.0122.086

315.61.0951.0292.124


1.0001.0001.0001.000

0.9861.0141.0311.016

1.0001.0001.0001.000

1.0001.0201.0171.018

NFSNFS performance has improved significantly as a result of several factors:

• APAR PQ16183, available on TCP/IP Function Level 310, improves theperformance of reading and writing Byte File System (BFS) files.

• Additional performance improvements that were incorporated into TCP/IP FL320 to improve the performance of various BFS and Shared File System(SFS) cases.

• Support for version 3 of the NFS protocol, included in TCP/IP FL 320. Thisincludes support for NFS requests exceeding 8 Kb, piggybacking of fileattribute information to minimize the number of trips between client andserver, and efficient access of file attributes using the readdirplus function.

• The CMS multitasking improvements included in VM/ESA 2.4.0 reduce NFSserver CPU time when accessing BFS files.

This section provides comparison data that quantify these benefits and,additionally, quantify the performance of the TCP support that has been added toNFS in TCP/IP FL 320.

Measurement DescriptionThe measured system consisted of a 9672-R55 (5-way) processor with VM/ESA2.4.0 running in a shared, 5-way LPAR. This system was attached to a 16 MbitIBM Token Ring through an OSA-2 adapter. NFS requests were made from anRS/6000 model 250 on the same token ring. The RS/6000 was running AIX 4.2.1,which includes support for both version 2 and version 3 of the NFS protocol. Themeasured configuration was not dedicated but all measurements were doneduring periods of negligible additional usage and all measurements wererepeated in order to ensure consistency.


Migration: TCP/IP

All accessed files were on 3390 DASD. Normal recommended CP tuning (largerelative share, QUICKDSP ON, minidisk caching enabled, etc) was in effect forthe server virtual machines that were active during the measurements (TCPIP,VMNFS, and the SFS/BFS server). The TCPIP server was configured to use anMTU size of 4000 bytes. Except where otherwise stated, the UDP buffer size(LARGEENVELOPEPOOLSIZE) and the TCP buffer size (DATABUFFERPOOLSIZE)were set to 16384.

The following four workloads were used to evaluate NFS performance:

Mount/Umount Mount a 60-file minidisk or directory for binary file access, thenunmount it.

Read 200 Kb Do the above mount request, read a 200 Kb file from VM, dothe above umount request.

Write 200 Kb Do the above mount request, write a 200 Kb file from VM(replacing the existing file), do the above umount request.

List 60 Files List the names and attributes of the 60 files in the previouslymounted minidisk/directory. All files have fixed length recordsand all file names follow the normal naming conventions forCMS files.

Measurement data were collected using the CP QUERY TIME command, the CPINDICATE USER command, and the QUERY FILEPOOL COUNTER commandissued before and after 10 workload invocations. Elapsed times were calculatedby the driver program on the AIX client. All results were divided by 10 so thatthe reported results represent an average of 10 trials.

Mount/umount were included as part of the “Read 200 Kb” workload in order toprevent AIX file caching after the first read invocation from affecting the results.Mount/umount were included in the write workload so as to be consistent withthe read workload. The “List 60 Files” workload did not include mount/umountprocessing as there is no AIX caching in this case.

These 4 workloads were run for files residing on a minidisk, in an SFS directory,and in a BFS directory. The following cases were measured:

• NFS at TCP/IP FL 310, version 2 NFS protocol, UDP transport



• NFS at TCP/IP FL 320, version 3 NFS protocol, TCP transport (minidisk caseonly)

The desired NFS version and transport protocol were specified on the mountcommand.

Results: TCP/IP FL 310 NFS V2 to TCP/IP FL 320 NFS V3Figure 1 and Figure 2 summarize the overall effect of migrating from TCP/IP FL310 and using the version 2 NFS protocol to TCP/IP FL 320 and using the version3 NFS protocol for the case of UDP transport. A ratio of 1.00 representsequivalence to TCP/IP FL 310 with V2 NFS. Ratios less than 1.00 representimproved performance. These same results, along with additional measurementdata, results for the intermediate case of TCP/IP FL 320 and NFS version 2, andresults using the TCP transport protocol are provided in Table 10 on page 35through Table 17 on page 38.


Migration: TCP/IP

Figure 1. Elapsed times relative to NFS at FL 310 for various NFS workloads

Figure 2. Total VM/ESA CPU times relative to NFS at FL 310 for various NFS workloads


Migration: TCP/IP

Additional measurements (not shown) confirmed that the performanceimprovement for the “Mount/Umount” workload is from the mount command.The performance of the umount command has not changed.

The especially large improvement observed for reading and writing BFS files isprimarily due to APAR PQ16183, which eliminates large numbers of BFS calls bykeeping the file open across NFS requests from the client.

The large improvements observed for the “List 60 Files” workload come from thereaddirplus interface that was added to the NFS protocol in version 3. Withversion 2, the client had to issue a separate NFS request for each object in themounted directory. With version 3, attribute data for all objects in the directorycan be returned to the client in response to a single readdirplus request. Forthese measurements, the files all had fixed length records. For minidisks ordirectories containing variable length files, the amount of improvement is muchless because the VMNFS server must still open each of the files in order todetermine the size of the file.

These results show that most of the performance improvements apply to NFSaccess to SFS and (especially) BFS files. This has tended to even out NFSperformance characteristics for NFS access to files stored in the three differentCMS file systems, as illustrated in Figure 3 for elapsed time. A similaruniformity improvement has also occurred for CPU usage.

Figure 3. Elapsed times relative to the minidisk case for various NFS workloads

These comparative results do not reflect the ability of the NFS version 3 protocolto support data transfers larger than 8 Kb. These additional benefits occur atlarger settings of LARGEENVELOPEPOOLSIZE (UDP) andDATABUFFERPOOLSIZE (TCP) for the TCPIP server virtual machine. See“Results: Large Buffers” on page 39 for additional information.


Migration: TCP/IP

The CMS multitasking improvements in VM/ESA 2.4.0 (see “PerformanceImprovements” on page 3) provide additional benefits for NFS access of BFSfiles by reducing the amount of CPU time used in the VMNFS server virtualmachine. These benefits are in addition to the performance benefits reflected inthis section, which are all based on measurements done on VM/ESA 2.4.0. Forexample, comparison of these results to other measurements (not shown) of the200K BFS read workload running on VM/ESA 2.3.0 CMS reveals an additional27% decrease in VMNFS server CPU usage and a 14% decrease in total systemCPU usage due to the CMS multitasking changes. NFS accesses to minidisk andSFS files are unaffected by these change because the VMNFS server does notuse CMS multitasking in those cases.

Measurement results indicate that the combined benefits from support for largedata transfers and from the CMS multitasking improvements result in a further11% elapsed time improvement beyond the 72% elapsed time improvementshown for the case of reading a 200 Kb BFS file in Figure 1, resulting in anoverall elapsed time improvement of 83% for this case when all improvementsare considered.


Migration: TCP/IP

Table 10. NFS Performance: Mount/Umount a CMS Minidisk

Run IdTCP/IP ReleaseNFS Protocol VersionTransport ProtocolVM File System

1M12U161310V2

UDPMinidisk

1M22U162320V2

UDPMinidisk

1M23U162320V3

UDPMinidisk

1M23T162320V3

TCPMinidisk

Elapsed Time (sec)Elapsed Time Ratio

0.411.000

0.360.894

0.360.891

0.370.901

CPU UsageVMNFS (sec)TCPIP (sec)Total (sec)Total Ratio

0.0170.0200.0371.000

0.0190.0180.0371.000

0.0200.0170.0371.000

0.0210.0220.0431.162

Virtual I/OVMNFS 6 5 5 5

Note: 9672-R55 shared LPAR, VM/ESA 2.4.0, 16 Mbit IBM Token Ring, OSA-2 Adapter, AIX 4.2.1client on RS/6000 250, binary transfer, 16 Kb transport buffers

Table 11. NFS Performance: Mount/Umount an SFS or BFS Directory


1S12U162310V2

UDPSFS

1S22U162320V2

UDPSFS

1S23U161320V3

UDPSFS

1B12U162310V2

UDPBFS

1B22U161320V2

UDPBFS

1B23U162320V3

UDPBFS


0.401.000

0.350.875

0.340.840

0.401.000

0.360.894

0.340.859

CPU UsageVMNFS (sec)TCPIP (sec)SFS/BFS ServerTotal (sec)Total Ratio

0.0170.0220.0040.0431.000

0.0170.0190.0030.0390.907

0.0150.0170.0020.0340.791

0.0270.0210.0110.0591.000

0.0220.0190.0050.0460.780

0.0190.0170.0040.0400.678

Virtual I/OVMNFSSFS/BFS Server

30

30

30

30

30

30

SFS/BFS RequestsSFS/BFS Time (sec)

80.002

70.002

40.001

170.005

70.004

50.003

Note: 9672-R55 shared LPAR, VM/ESA 2.4.0, 16 Mbit IBM Token Ring, OSA-2 Adapter, AIX 4.2.1 client on RS/6000 250,binary transfer, 16 Kb transport buffers

“SFS/BFS Requests” and “SFS/BFS Time” are taken from the QUERY FILEPOOLCOUNTER data. “SFS/BFS Requests” is from the “Total File Pool Requests”counter, while “SFS/BFS Time” is from the “File Pool Request Service Time”counter and represents elapsed time spent in the SFS/BFS server handling thoserequests during the measured interval.


Migration: TCP/IP

Table 12. NFS Performance: Read a 200K Minidisk File


RM12U162310V2

UDPMinidisk

RM22U162320V2

UDPMinidisk

RM23U162320V3

UDPMinidisk

RM23T162320V3

TCPMinidisk


0.741.000

0.700.941

0.771.040

1.031.380


0.0720.0840.1561.000

0.0780.0840.1621.038

0.0800.0890.1691.083

0.0900.1160.2061.321



Table 13. NFS Performance: Read a 200K SFS or BFS File


RS12U162310V2

UDPSFS

RS22U162320V2

UDPSFS

RS23U162320V3

UDPSFS

RB12U162310V2

UDPBFS

RB22U162320V2

UDPBFS

RB23U162320V3

UDPBFS


0.841.000

0.800.952

0.800.951

2.521.000

0.690.274

0.710.282


0.1240.0620.0900.2761.000

0.1160.0600.0810.2570.931

0.1230.0630.0840.2700.978

0.4480.0680.3450.8611.000

0.1190.0620.0500.2310.268

0.1210.0650.0520.2380.276


376

376

376

384

33

32


2170.19

1900.20

1920.19

4861.45

660.08

670.06



Migration: TCP/IP

Table 14. NFS Performance: Write a 200K Minidisk File


WM12U162310V2

UDPMinidisk

WM22U162320V2

UDPMinidisk

WM23U162320V3

UDPMinidisk

WM23T162320V3

TCPMinidisk


2.791.000

2.831.014

2.931.050

3.001.076


0.0790.1010.1801.000

0.0910.1080.1991.106

0.0940.1090.2031.128

0.1040.1320.2361.311



Table 15. NFS Performance: Write a 200K SFS or BFS File


WS12U162310V2

UDPSFS

WS22U161320V2

UDPSFS

WS23U162320V3

UDPSFS

WB12U162310V2

UDPBFS

WB22U162320V2

UDPBFS

WB23U162320V3

UDPBFS


4.281.000

3.760.879

3.860.901

3.031.000

2.680.884

2.480.818


0.2370.0700.2510.5581.000

0.2390.0710.2460.5560.996

0.2410.0750.2520.5681.018

0.5640.0730.4591.0961.000

0.2660.0720.2000.5380.491

0.2800.0760.2120.5680.518


3260

3257

3261

383

383

381


4853.50

4523.04

4563.14

6231.78

2011.86

2041.65



Migration: TCP/IP

Table 16. NFS Performance: List Contents of a 60-File Minidisk


LM12U162310V2

UDPMinidisk

LM22U162320V2

UDPMinidisk

LM23U162320V3

UDPMinidisk

LM23T162320V3

TCPMinidisk


0.241.000

0.230.970

0.180.738

0.220.907


0.0090.0150.0241.000

0.0090.0150.0241.000

0.0070.0070.0140.583

0.0070.0080.0150.625



Table 17. NFS Performance: List Contents of a 60-File SFS or BFS Directory


LS12U161310V2

UDPSFS

LS22U162320V2

UDPSFS

LS23U162320V3

UDPSFS

LB12U162310V2

UDPBFS

LB22U162320V2

UDPBFS

LB23U162320V3

UDPBFS


0.561.000

0.631.133

0.170.306

0.811.000

0.640.789

0.580.719


0.0700.0520.0420.1641.000

0.0860.0650.0520.2031.238

0.0090.0080.0050.0220.134

0.1660.0310.1210.3181.000

0.0480.0250.0260.0990.311

0.0390.0170.0230.0790.248


02

02

01

00

01

01


1030.04

1210.04

90.01

1980.06

360.03

330.03



Migration: TCP/IP

Results: TCP SupportNFS at TCP/IP FL 310 only supported the UDP protocol. With TCP/IP FL 320, NFShas added support for the TCP protocol. A set of measurements was obtained tocompare NFS performance when using the UDP and TCP transport protocols.These measurements were obtained for the case of binary access to minidiskfiles using TCP/IP FL 320 and NFS version 3. The results are summarized below,with further details provided in Table 10, Table 12, Table 14, and Table 16.

Table 18. Effect of transport protocol on NFS performance

MeasureTransport Protocol

ETUDP

ETTCP

ETPct

TCPUUDP

TCPUTCP

TCPUPct

Mount/UmountRead 200 KbWrite 200 KbList 60 Files

0.360.772.930.18

0.371.033.000.22

334

222

0.0370.1690.2030.014

0.0430.2060.2360.015

162216

7

Note: ET = Elapsed Time (sec), TCPU = Total system CPU usage (sec); 9672-R55 shared LPAR, VM/ESA 2.4.0, 16 MbitIBM Token Ring, OSA-2 Adapter, AIX 4.2.1 client on RS/6000 250, TCP/IP 320, NFS version 3, minidisk files, binary transfer,16 Kb transport buffers

These results indicate that NFS performance tends to be somewhat better whenthe UDP protocol is used.

These results are for the case of NFS access to minidisk files. The UDP to TCPperformance relationship should be similar for NFS access to SFS or BFS files.

Results: Large BuffersWhen reading or writing large files, NFS performance is significantly affected bythe number of bytes requested by the client per request. The larger this is, thefewer NFS requests are required, and the better the performance.

When the NFS version 2 protocol is used by an NFS client, the VMNFS server canread or write a maximum of 8 Kb. This is a limitation of the version 2 protocoland applies to both the UDP and TCP transport protocols. With version 3, this 8Kb limit has been removed, creating the potential for improved performancewhen reading or writing large files.

For the NFS version 3 protocol, the VMNFS server defines maximum andpreferred read and write data transfer sizes based on TCP/IP transport layerbuffer sizes defined in the PROFILE TCPIP (or nodename TCPIP) configurationfile. For UDP-connected clients, the maximum and preferred read and writesizes are based on the buffer size specified on the LARGEENVELOPEPOOLSIZEstatement. For TCP-connected clients, these are based on the buffer sizespecified on the DATABUFFERPOOLSIZE statement2.

When using the NFS version 3 protocol, NFS clients can determine thesemaximum and preferred sizes and use this information to help determine theactual data transfer sizes they should use when making requests to the VM NFSserver. Exactly how this information is used will vary from one clientimplementation to another.

2 For DATABUFFERPOOLSIZE values greater than 64 Kb, the VMNFS server uses 64 Kb to compute the maximum andpreferred read and write sizes. The largest DATABUFFERPOOLSIZE value supported by TCP/IP for VM is 256 Kb.


Migration: TCP/IP

For additional information, refer to the “Configuring the NFS Server” chapter inthe TCP/IP Function Level 320 Planning and Customization manual.

Two sets of measurements were obtained for NFS binary read of a 200 Kbminidisk file using various TCP/IP transport layer buffer sizes. For one set, theNFS client used the UDP transport protocol, while for the other set, TCP wasused. The results are summarized in the following table.

Table 19. NFS read of a 200Kb minidisk file: Effect of UDP/TCP buffer size

Run IdTransport ProtocolBuffer Size (bytes)

RM23U082UDP8192

RM23U164UDP

16384

RM23U321UDP

32768

RM23T082TCP8192

RM23T164TCP

16384

RM23T323TCP

32768

Maximum/Preferred (bytes)Max Transfer (bytes)Elapsed Time (sec)Elapsed Time Ratio

878483200.76

1.000

1595283200.76

0.990

3233616512

0.710.925

778442241.23

1.000

1597683201.01

0.818

3236016512

1.050.849


0.0730.0790.1521.000

0.0710.0780.1490.980

0.0560.0580.1140.750

0.1150.1630.2781.000

0.0830.1090.1920.691

0.0650.0790.1440.518

Virtual I/OVMNFSTCP/IPTCP/IP I/O Ratio

84931

1.000

84925

0.994

84682

0.733

842646

1.000

841581

0.598

841123

0.424

Note: 9672-R55 shared LPAR, VM/ESA 2.4.0, 16 Mbit IBM Token Ring, OSA-2 Adapter, AIX 4.2.1 client on RS/6000 250,binary transfer TCP/IP 320, NFS version 3

“Maximum/Preferred” refers to the maximum and preferred values that wereselected by the VMNFS server. This information was obtained by issuing theSMSG VMNFS M Q CONFIG command. The maximum read, maximum write, andpreferred values were the same.

The maximum number of bytes transferred per NFS read request (“MaxTransfer”) was determined for each case. This was done by looking at thelengths returned to the client in a 501 trace (SMSG VMNFS M MASK 501). Theselengths include both data and header bytes.

Note that the maximum and preferred values selected by the VMNFS server arenormally slightly smaller than the corresponding TCP/IP stack configurationvalues. This is to allow space for the RPC header information that is required onall data transfers. The UDP 8192 case is an apparent exception to this. When aLARGEENVELOPEPOOLSIZE of 8192 bytes is specified, the TCP/IP stack actuallycreates 9216-byte (9 Kb) UDP buffers in order to accommodate the specialrequirements of the NFS version 2 protocol and the ATM protocol. It is this 9216value that the TCP/IP stack communicates to the VMNFS server, resulting in theobserved 8784 maximum and preferred values.

Note that, except for the UDP 8192 case, the maximum number of bytestransferred per NFS read request is only about half the size of themaximum/preferred values advertised by the VMNFS server. This resultillustrates the fact that the actual number of bytes per read is determined by theclient. When our AIX client sees that the maximum/preferred value is not, forexample, a full 16 Kb, it decides to receive data in increments of half that size.Other clients may instead, for example, choose to use the maximum/preferredvalue or drop down to the next 1 Kb multiple.


Migration: TCP/IP

When the transport buffer is specified as 8 Kb, NFS with UDP performs especiallywell relative to NFS with TCP. This is because NFS with UDP gets to transferdata 8 Kb at a time (due to the special case 9 Kb transport buffer mentionedabove), while NFS with TCP transfers data 4 Kb at a time because the clientdrops down to half the buffer size when it finds that the full 8 Kb is not available.

As Max Transfer increases, the number of NFS requests needed to transfer thedata decreases. This causes TCPIP I/Os, TCPIP CPU usage, and VMNFS CPUusage to also decrease. This improved performance is possible because theNFS version 3 protocol supports data transfer in increments larger than 8 Kb.


Migration from Other VM Releases


The performance results provided in this report apply to migration from VM/ESA2.3.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



240 VM/ESA Version 2 Release 4.0 Performance Report (thisdocument)

See “Referenced Publications” on page vii 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.2.0 to VM/ESA 2.4.0 will tend to affect VSE guestperformance, look at the VM/ESA 2.2.0 to VM/ESA 2.3.0 comparisonmeasurements and the VM/ESA 2.3.0 to VM/ESA 2.4.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 44.



Table 20. 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

230230

230

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

240240

240

Migration from Other VM Releases 43


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 21 summarizes the approximate ITR relationships for the CMS-intensiveenvironment for migrations to VM/ESA 2.4.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.4.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 21. Approximate VM/ESA 2.4.0 relative capacity: CMS-intensive environment

Source Case ITRR Notes

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

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

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

0.981.05

2,5-74-7

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

0.961.03

2,5-74-7

VM/SP HPO 5 UPMP

0.991.10

4,6,73,4,6,7

VM/XA 2.0 1.22 7

VM/XA 2.1 1.19 7

VM/ESA 1.0 ESA 1.15 7

VM/ESA 1.1 1.10 7

VM/ESA 2 1.09 7

VM/ESA 2.1 1.08 7

VM/ESA 2.2 1.05 7

VM/ESA 2.1.0 1.00

VM/ESA 2.2.0 0.99

VM/ESA 2.3.0 0.99



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.4.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.4.0 system hasadditional real storage.

For example, the stated VM/SP HPO 5 to VM/ESA 2.4.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.

Migration from Other VM Releases 45


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 21 on page 44 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.4.0. FromTable 21 on page 44, the estimated ITRR for migrating from VM/ESA 2.1 toVM/ESA 2.4.0 is 1.08. Therefore, the estimated overall increase in systemcapacity is 1.30*1.08 = 1.40.

Table 21 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.


LIMITHARD Share Capping Option

Additional Evaluations

This portion of the report includes results from a number of additional VM/ESAand VM/ESA platform performance measurement evaluations that have beenconducted during the past year.

LIMITHARD Share Capping OptionThe LIMITHARD option of the SET SHARE command has been available sinceVM/ESA 1.2.2. Use of the LIMITHARD option allows a cap or limit to be placedthe processor resources used by a virtual machine. While LIMITHARD proved tobe very effective for most customers, it was less accurate in certainenvironments. In particular, the LIMITHARD capping seemed overly aggressivefor systems where the total processor utilization was low. In VM/ESA 2.4.0,changes have been made to improve the tracking of the limit share values forthe LIMITHARD option. Figure 4 illustrates the improvements.

Figure 4. LIMITHARD tests with a user share setting of REL 100 ABS 20% LIMITHARD ona 9121-742.

In the tests shown above, a processor intensive job was run in a user that hadan absolute 20% hard limit. The absolute setting is of the system, which in thiscase had four processors (9121-742). Therefore the target maximum was 80% ofa single processor. The dashed line in Figure 4 represents this targetmaximum. Two scenarios were run for each release. In the first one, the overallsystem utilization was above 95%, while in the second one the overall systemutilization was below 30%. For the VM/ESA 2.3.0 runs, the user is limited morethan the hard limit, while the VM/ESA 2.4.0 user is held very close to the targetmaximum.

The limit hard accuracy has been improved. However, in an LPAR environment,results can still be unpredictable. Tests performed at IBM showed that in a


Reusable Server Kernel

shared LPAR environment the user was limited more the the limit hard setting.One early support program customer saw the opposite results. In their LPARenvironment, the limited user received more than the target maximum.

A side effect of the improved share limit accuracy is that the system overheadincreases when a limited user is being held back. The amount of overhead isalso dependent on the minor dispatch slice. For the tests run above with adefault minor dispatch slice, system processor usage increased from 0.4% to1.9%.

Reusable Server KernelThe Reusable Server Kernel (RSK) is an execution framework that facilitates thewriting of high performance servers on VM/ESA. The RSK provides functionalitythat is needed by all or many VM servers, thus freeing the server writer toconcentrate on providing the application-specific functions. This section takes alook at the performance of some of the RSK functions.

The RSK code, first made available on VM/ESA 2.2.0 and VM/ESA 2.3.0 via APARVM61878, is now shipped with VM/ESA 2.4.0. The user′s manual, sample server,and supplementary information are available at http://www.ibm.com/s390/vm/rsk.

The measurements make use of the ECHO and SGEXER commands provided inthe SSTEST sample server. They also made use of some thin scaffolding builtaround the ssWorkerAllocate API.

All measurements were obtained on a 9121-480 (2-way) processor runningVM/ESA 2.3.0. Each measurement consisted of 1 to 8 equivalent client virtualmachines sending commands to the RSK server virtual machine using the CPMSG command. After all clients were started, this activity was measured for afixed time interval. Commands executed and average response time werecollected for each client and aggregated over all clients. In addition, CP monitorrecords were collected for each measurement and reduced by VMPRF.

Echo ResultsThe SSTEST ECHO command simply responds to the client with the characterstring that was sent. This command provides a good measure of baselineperformance (no application content) and exercises RSK code that is common toall RSK server requests. Table 22 contains results for this workload at variousnumbers of clients. For these measurements, each client waited 5 msecbetween echo commands, the measurement interval was 1 minute, and 3 byteswere sent/returned.

Table 22. RSK Performance: Echo Command

clientsrun id

1E005C1A

4E005C4A

6E005C6A

8E005C8A

commands/secresponse time (msec)total CPU utilization

56.04.5

27.7

163.99.1

77.3

190.813.889.5

192.724.491.8

RSK serverTotal CPU utilizationTotal CPU/cmd (msec)Virtual CPU/cmd (msec)CP CPU/cmd (msec)

183.22.11.1

523.22.11.1

623.22.21.0

643.32.31.0

Note: 9121-480, VM/ESA 2.3.0, 5 msec think time



The results indicate that:

• Throughput is limited by processor usage and waiting for processor time. At8 clients, total processor utilization was about 92%. Processor utilizationpeaked at significantly less than 100% because CP MSG was used forclient/server communications. Some of the CP code that implements the CPMSG facility must run on the master processor. As a result, the client andserver virtual machines spent some of their time waiting to get the masterprocessor. This shows up as ″waiting on console function″ in theUSER_STATES VMPRF report. If, for example, the IUCV line driver wereused instead, maximum processor utilization should be nearly 100%because none of the IUCV code requires the master processor.

• Processor usage per command is essentially independent of load.

These results were compared to similar results collected for echo requests sentto an SFS server virtual machine, as approximated by the QUERY FILEPOOLCONNECT command. Those results were similar except that 1) maximum CPUutilization was over 99% because APPC was used for communications (likeIUCV, APPC does not require the master processor) and 2) server total CPU timeper command was about 63% lower. RSK uses the generalized CMSmultitasking interfaces to achieve multithreading, while SFS uses its ownsubdispatching mechanism that has been tailored to its requirements.

Storage Group ResultsThe SSTEST SGEXER command was used to write and then read the first 50storage group blocks, 10 blocks at a time. Measurements were made with 1 and2 clients. For the 2-client measurements, each client used a different storagegroup and those storage groups were implemented on separate DASD volumes.This was done in order to verify that an I/O by one client does not block theother client from continuing to run and doing an I/O at the same time. A pair ofmeasurements was obtained for the following two cases:

• The storage groups were implemented as VM data spaces mapped tominidisks that were disabled for minidisk caching.

• The storage groups were implemented as minidisks enabled for minidiskcaching and accessed using asynchronous Diagnose X′250′.

The measurement results are summarized in Table 23.

Table 23. RSK Performance: Storage Group Usage

storage group typeminidisk cachingclientsrun id

DSdisabled

1GTDS1M0A

DSdisabled

2GTDS2M0A

D250enabled

1GTBS1A

D250enabled

2GTBS2B

commands/secresponse time (msec)total CPU utilization

8.63115.4

16.0

16.78118.8

27.9

8.42118.3

17.5

16.28122.4

30.5

RSK serverTotal CPU/cmd (msec)Virtual CPU/cmd (msec)CP CPU/cmd (msec)DASD IOs/secDASD IOs/cmdDASD response (msec)

23.216.2

7.043.4

5.017.8

22.616.7

6.084.7

5.017.9

26.114.311.942.3

5.017.8

27.013.513.582.0

5.017.9

Note: 9121-480, VM/ESA 2.3.0, no think time, write and then read 50 blocks, 10 blocks per I/O,each client uses a separate storage group on a separate DASD volume, no paging

Addit ional Evaluations 49


The fact that throughput doubles when going from 1 to 2 clients indicates that, inboth the data space and Diag 250 cases, there is effective overlap of processingfor the two clients. It also indicates that throughput would have gonesubstantially higher had additional, equivalently configured clients and storagegroups been present.

The data space case was run with minidisk caching disabled. This is therecommended tuning for minidisk-mapped data spaces because it avoids theextra overhead of caching the file data twice.

Performance of the data space and the Diag 250 cases was similar, withsomewhat lower processor usage for the data space case. Data spaces are agood choice when the number of frequently accessed blocks is sufficiently smallrelative to real memory size that little paging occurs. When a page I/O occurs,all threads in the server machine are blocked until that I/O completes.Therefore, Diag 250 is a better choice when large amounts of data are involved.

Worker Machine ResultsTo evaluate the RSK′s worker machine function, some scaffolding was buildaround ssWorkerAllocate such that a CP MSG to the RSK would cause a verybrief worker transaction. ssWorkerAllocate would be called to connect to aworker, the worker would be sent 4 Kb of data (which it would discard), and thenthe connection to the worker would be closed. Resource consumption by thisbrief transaction is indicative of the RSK′s overhead in selecting a workermachine and establishing a connection to it.

Table 24 summarizes the results obtained for the case of 1 to 3 clientsexercising this workload with a 5 second think time between requests. The 5available worker machines were all logged on before the measurement.

The achievement of higher throughputs when the number of clients is increasedverifies that the client virtual machines, the RSK server, and the worker virtualmachines are able to do work concurrently with a high level of independence.

Table 24. RSK Performance: Echo to Worker Machines

clientsrun id

1W05C1A

2W05C2A

3W05C3A

commands/secresponse time (msec)

34.315.0

35.042.0

45.148.5

total CPU utilization 65.6 66.7 89.7

RSK serverTotal CPU utilizationTotal CPU/cmd (msec)Virtual CPU/cmd (msec)CP CPU/cmd (msec)

4613.4

9.34.0

4613.3

9.34.0

6013.4

9.44.0

workersTotal CPU/cmd (msec)Virtual CPU/cmd (msec)CP CPU/cmd (msec)

15.18.07.0

15.18.17.0

17.49.08.3

totalTotal CPU/cmd (msec)Virtual CPU/cmd (msec)CP CPU/cmd (msec)

28.517.411.1

28.417.311.0

30.718.412.3

Note: 9121-480, VM/ESA 2.3.0, 5 second think time, 5 worker machines


Tivoli ADSM Version 3

These results and the USER_STATES VMPRF report suggest that maximumthroughput is being limited by the capacity of the RSK server which, in turn, islimited by processor usage, waiting for processor time, and waiting for themaster processor. Total processor utilization of nearly 90% for the 3-client caseshows that, additionally, throughput is close to being limited by total processingcapacity.

These results show higher processor usage per command than the echo resultspresented in Table 22 as a result of using a separate worker virtual machine toperform the echo function.

Tivoli ADSM Version 3Tivoli ADSM for VM Version 3 includes a number of significant performanceimprovements. This section provides measurement results that assess theperformance differences between ADSM Version 2 and Version 3. Tuninginformation is also provided.

Measurement DescriptionThe ADSM server virtual machine (DSMSERV) was run on a 9121-480 (2-way)processor running VM/ESA 2.3.0 and TCP/IP Function Level 310. The files to bebacked up or restored were on one or two RS/6000 model 250 clientworkstations. The workstation used for the single client runs was running AIX4.2.1, while the workstation that was added for the 2-client runs was running AIX4.1.4. These workstations were connected to the VM/ESA system via 16 MbitIBM Token Ring. The VM/ESA system was connected to the token ring through a3172-3 communications controller.

Measurements were made using ADSM for VM Version 2 (V2) and Version 3(V3). For all measurements, the version of ADSM client code used was the sameas the version of the ADSM server code being run on VM/ESA.

Three different workloads were measured — backup of files from 1 clientworkstation to a disk storage pool, backup of files from 2 client workstations to adisk storage pool, and restore of those files for 1 client to that workstation. Foreach of these cases, a separate measurement was obtained for each of 5different file sizes — 1KB, 10KB, 100KB, 10Mb, and 256Mb. This is the sameworkload that is used by the ADSM performance team to evaluate ADSMperformance on other platforms. No earlier backup copies of the files beingbacked up were already in the storage group. Likewise, the files being restoreddid not already exist on the client.

CP monitor data (later reduced by VMPRF) and the AIX console were collectedfor each measurement. MB transferred and elapsed time were taken from theAIX console and used to calculate KB/sec. The remaining data were obtainedfrom the VMPRF reports or derived from a combination of the VMPRF data andthe AIX console information.

Preliminary Tuning ExperimentsThese workloads were first run with no special tuning in either the client orserver systems. Several experiments were then performed using backup of a10M file as the workload in order to assess the impact of various tuningchanges. This resulted in a more optimal set of tuning settings, which were thenused to obtain the results provided here.

Additional Evaluations 51


This tuning is summarized in Table 25, which shows the default values, thetuning settings used for the “untuned” baseline runs (often the default values),the final tuning settings used for the tuned runs, and the approximate degree ofbenefit relative to the untuned setting that was observed for the test workload.

A “?” in the benefit column indicates a tuning change that was made based on adocumented recommendation, but not verified by these informal measurements.

The client ADSM options are in the dsm.sys file. The AIX client TCP/IPparameters are set using the “no” AIX command, except for MTU, which is setusing “smit tcpip.” The TCP/IP VM parameters are set in the PROFILE TCPIPfile, while the ADSM for VM server options are in the DSMSERV OPT file.

In addition to the tuning listed above, the normal CP tuning recommended forserver virtual machines was done for the TCPIP and DSMSERV server virtualmachines. This included the QUICKDSP option, larger than default (100) relativeSHARE settings, and use of minidisk caching for DSMSERV′s minidisks.

The combined effect of these tuning actions on overall performance wassubstantial. Throughput increased by 17% to 190%, while total VM/ESA CPUusage decreased by 5% to 40% relative to the untuned configuration. The largerthe file size, the larger the improvement.

It is interesting to note that even though the tuned configuration showed muchgreater absolute performance than the untuned configuration, bothconfigurations showed a very similar pattern and degree of performanceimprovement when going from ADSM V2 to V3. This indicates that the V3improvements are likely to express themselves to a similar degree across awide variety of ADSM configurations.

Table 25. Tuning settings used for untuned and tuned ADSM measurements

Tuning Parameter default untuned tuned benefit

AIX client: ADSMtcpbufsizetcpwindowsizetxnbytel imit

816

200

816

200

3264

25600

somelarge

?

AIX client: TCP/IPtcp_sendspacetcp_recvspaceMTU size

409640961492

1638416384

1492

6553665536

2000

largelargesome

VM: TCPIP serverdatabufferpoolsizeMTU size

8192576

81924000

655364000

largen/c

VM: ADSM servertxngroupmax 16 16 256 ?

Results SummaryPerformance was nearly always better with ADSM V3, both in terms ofthroughput and VM CPU and I/O resource usage. For backup, throughputimprovements ranging from 7% to 188% were observed, while VM CPU and I/Ousage 3 improved by 17% to 66% and by 77% to 87% respectively. Restoreimprovements were smaller. Throughput improvements ranged from -3% to



15%, while VM CPU and I/O usage improved by 21% to 52% and by 0% to 47%respectively.

For both backups and restores, the largest percentage improvements wereobserved for the smallest (1KB) files. For small files, the performanceimprovements are mostly due to a V3 enhancement known as “server fileaggregation” which groups together data from multiple small files and transfersthem as a single unit. Performance also improved for large files, although to asmaller extent, primarily due to the new “uselargebuffers” server option (whichis the default).

Environments characterized by high levels of DSMSERV loading that result inprocessor and/or I/O contention will tend to experience higher levels ofimprovement when migrating from V2 to V3 than those shown in this report.This higher degree of improvement will result from the large decreases in CPUand I/O usage that were achieved in V3. See “Backup Results: 2 Clients” onpage 55 for further discussion.

In nearly all cases, throughput was primarily limited by the relatively highlatencies associated with the network hardware configuration that was used forthese measurements. Faster network configurations can be expected to deliverhigher throughputs than those observed here.

The tuned configuration results for 1 client backup, 2 client backup, and 1 clientrestore are presented and discussed in the following three sections.

3

CPU usage refers to total system CPU time per KB transferred. I/O usage refers to the count of virtual DASD I/Os issued bythe DSMSERV server virtual machine per KB transferred. Because of minidisk caching, not all of these virtual I/Os result inreal I/Os.

Addit ional Evaluations 53


Backup Results: 1 Client

The CPU and DASD I/O data in these tables and in the tables to follow pertain tothe VM/ESA system. Nearly all of the CPU usage is from the DSMSERV andTCPIP virtual machines, while nearly all of the DASD I/Os are from theDSMSERV virtual machine.

Note that ADSM throughput and efficiency improves greatly with increasing filesize. There is a significant amount of processing required for each file that isindependent of file size. This constant amount of per-file processing becomes aninsignificant part of total processing as file size becomes very large. The“server file aggregation” improvement reduces this per-file processing and, assuch, is a key improvement for small files but has no effect on the performanceof large file transfers.

Table 26. Backup 1 client: ADSM V2

File Size 1KB 10KB 100KB 10MB 256MB

M B TransferredElapsed Time (sec)CPU UtilizationDASD I/O rate (/sec)DASD Response (msec)

12.2410

37.234.7

8.1

20.083

36.330.712.0

50.086

17.528.113.2

100.0147

14.423.814.8

257.9371

13.324.814.9

DSMSERV CPU UtilTCPIP CPU Util

648

5911

1616

1016

717

KB/secTotal CPU/KB (msec)DASD IOs/KB

3124.39

1.14

2472.940.12

5970.590.05

6970.410.03

7120.370.03

Note: 9121-480, VM/ESA 2.3.0, 16 Mbit IBM Token Ring, 3172-3, AIX 4.2.1 client on RS/6000 250

Table 27. Backup 1 client: ADSM V3



12.3182

31.410.819.5

20.052

23.69.0

37.1

50.080

13.96.4

56.3

100.0134

11.75.6

74.0

258.0341

11.95.5

75.4


4218

2818

916

318

418


699.110.16

3971.190.02

6390.430.01

7670.310.01

7750.310.01


Table 28. Backup 1 client: V3/V2 ratios



1.000.440.840.312.41

1.000.620.650.293.09

1.000.930.790.234.27

1.000.910.810.245.00

1.000.920.890.225.06


0.662.26

0.471.56

0.541.00

0.331.13

0.491.06


2.260.370.14

1.600.410.18

1.070.740.21

1.100.740.21

1.090.820.20




Note that DASD response time increases as DASD I/Os per KB decrease sincemore data, on average, is being transferred per I/O.

Backup Results: 2 Clients

For these measurements, elapsed time was from first client start until last clientend. For all measurements, the two clients started and completed their ADSMbackups at nearly the same times.

Note that for 1KB file backup, there was a 2.88x throughput increase from V2 forthe 2-client measurements as compared to only a 2.26x throughput increase forthe 1-client measurements. This greater improvement results from the greatlyreduced DSMSERV CPU usage in V3. With V2, DSMSERV CPU utilization with 1client was 64%. Since DSMSERV CPU utilization cannot exceed 100%, this

Table 29. Backup 2 clients: ADSM V2



24.4640

49.545.5

8.1

40.0127

47.439.613.1

100.0147

22.831.813.6

200.0260

15.427.214.9

515.8659

15.527.214.7


8610

7814

2419

919

920


3925.36

1.17

3232.930.12

6990.650.05

7870.390.03

8020.390.03

Note: 9121-480, VM/ESA 2.3.0, 16 Mbit IBM Token Ring, 3172-3, 2 AIX clients on RS/6000 250

Table 30. Backup 2 clients: ADSM V3



24.5224

49.117.119.7

40.171

34.313.935.7

100.0132

16.77.9

56.1

200.0254

13.16.3

69.9

516.0653

12.95.6

77.1


6628

4027

1120

420

420


1128.740.15

5781.190.02

7750.430.01

8070.320.01

8090.320.01


Table 31. Backup 2 clients: V3/V2 ratios



1.000.350.990.382.43

1.000.560.720.352.73

1.000.900.730.254.13

1.000.980.850.234.69

1.000.990.830.215.24


0.772.82

0.511.87

0.441.08

0.481.02

0.421.02


2.880.340.13

1.790.400.20

1.110.660.22

1.030.830.23

1.010.830.20




means that, with V2, a doubling of the backup load by adding a second clientcannot be accommodated without a substantial elapsed time increase. With V3,DSMSERV CPU utilization with 1 client was only 42%, resulting in much greatercapacity to absorb an increased load without much increase to elapsed time.This effect was much less important for the larger file sizes because theDSMSERV CPU utilizations for these cases were much lower. As a result, thepercentage throughput increases relative to V2 for the larger file sizes werequite similar when comparing the 1-client and 2-client measurements.

Generalizing from the above discussion, it is reasonable to conclude thatenvironments characterized by high levels of loading that result in DSMSERVprocessor and/or I/O contention will tend to experience higher levels ofimprovement when migrating from V2 to V3 than those shown in this report.This higher degree of improvement results from the large decreases in CPU andI/O usage that were achieved in V3.



Restore Results: 1 ClientTable 32. Restore 1 client: ADSM V2



12.2555

31.94.6

18.3

20.0111

30.46.5

20.5

50.0204

13.16.9

21.5

100.0270

14.29.4

22.5

258.0695

12.69.4

22.9


602

518

1212

916

517


22.528.32

0.20

184.83.290.04

251.41.040.03

378.70.750.02

379.90.660.02


Table 33. Restore 1 client: ADSM V3



12.27504.3

17.02.714

20.0596.724.5

6.719.5

50.02206.2

10.26.621

100279.9

8.99.1

22.1

257.94707.4

8.49.2

22.4


301

406

99

312

112


2513.65

0.11

2122.310.03

2480.820.03

3660.490.02

3730.450.02


Table 34. Restore 1 client: V3/V2 ratios



1.010.910.530.590.77

1.000.870.811.030.95

1.001.010.780.960.98

1.001.040.630.970.98

1.001.020.670.980.98


0.510.84

0.790.80

0.790.72

0.280.76

0.270.73


1.110.480.53

1.150.700.90

0.990.790.97

0.970.651.00

0.980.681.00



CMS-Intensive (FS8F)

Appendix A. Workloads

The workloads that were used to evaluate VM/ESA 2.4.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 35shows 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 71 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 35. 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 36 on page 60.

Appendix A. Workloads 59


Table 36. 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


VSE Guest (DYNAPACE)

VSE Guest (DYNAPACE)

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 distributedover 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

� � �� !� � � � � �� " # "" � $�� " � #�� %� ��" � � � � "�" ��"&� � � �

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:� � �� !� � � � � �� " # "" � $�� " � #�� %� ��" � � � � "� � �� '�)(* � � � +!

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.


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_Time 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_Time 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_Transmi 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_Transmi 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_Time 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_Time 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_Transmi 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_Transmi t s tTPNS_T ime t

Think_Time 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 _BIO _Reques t _T ime fSFSTIME f


Tota l _BIO _Reques ts fSFSTIME f

Total_BIO_Request_Time 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 _BIO _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_Time 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_Time is from the QUERY FILEPOOL STATUS command.



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.

Glossary of Performance Terms 73


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 X′ 04′instructions used per command. DIAGNOSE codeX′ 04′ 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 X′ 08′instructions used per command. DIAGNOSE codeX′ 08′ 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 codeX′ 0C′ instructions used per command. DIAGNOSEcode X′ 0C′ 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 X′ 10′instructions used per command. DIAGNOSE codeX′ 10′ 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 X′ 14′instructions used per command. DIAGNOSE codeX′ 14′ 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 X′ 58′instructions used per command. DIAGNOSE codeX′ 58′ 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 codeX′ 7C′ instructions used per command. DIAGNOSEcode X′ 7C′ , 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 X′ 98′instructions 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 X′ 98′ 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 codeX′ A4′ instructions used per command. DIAGNOSEcode X′ A4′ 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 codeX′ A8′ instructions used per command. DIAGNOSEcode X′ A8′ 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 codeX′ 214′ instructions used per command. DIAGNOSEcode X′ 214′ is used by the Pending Page Releasefunction. This is calculated by:

DIAG_214

RTM_Time × ETR (T)



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

DIAG_268

RTM_Time × ETR (T)



DIAG 270/CMD. The number of DIAGNOSE codeX′ 270′ instructions used per command. DIAGNOSEcode X′ 270′ 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 X′ 0C′ 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_Time

is 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

Q0 t + Q0Lt + Q1 t + Q1Lt + Q2 t + Q2Lt + Q3 t + Q3Lt

Q0 t, Q0L t .. 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

E0 t + E0Lt + E1 t + E1Lt + E2 t + E2Lt + E3 t + E3Lt

E0 t, E0L t .. 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 Jobs

are 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 _Transmi 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 _Transmi 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 _BIO _Reques t _T ime fSFSTIME f

Total_BIO_Request_Time 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 Jobs

are 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:

ITRITR 1

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 f irst 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:


Rol 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 l icensed 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_Time 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 _I n 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

Virt_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)


Documents

Virtual Machine/ Enterprise Systems Architecture ... · PEEK is often used to view the beginning of a large reader file (PEEK defaults to reading the first 200 records).With VM/ESA