Version 2022-02-23
To check for possible updates to this document, please see
https://www.spec.org/sert2/SERT-resultfilefields.html
This document describes the various fields in the SPEC® SERT® 2 result disclosure. The different result files are available in HTML and TXT format.
Selecting one of the following will take you to the detailed table of contents for that section:
1. SPEC SERT
3. Top Bar
4. Summary
6. SUT Notes
10. Aggregate Electrical and Environmental Data
11. Worklet Performance and Power Details
1. SPEC SERT
1.1 Test harness - Chauffeur
1.1.1 SERT Director
1.1.2 SERT Host
1.1.3 SERT Client
1.1.4 SERT Reporter
1.1.5 SERT Graphical User Interface
1.2 Workloads
1.3 The Power and Temperature Daemon
1.4 Result Validation and Report Generation
1.5 References
2. Main Report File
3. Top bar
3.1 Test sponsor
3.2 Software Availability
3.3 Tested by
3.4 Hardware/Firmware Availability
3.5 SPEC license #
3.6 System Source
3.7 Test Location
3.8 Test Date
3.9 SERT 2 Efficiency Score / SERT 2 DC Efficiency Score
4. Summary
4.1 Summary Chart
4.2 Aggregate SUT Data
4.2.1 Model
4.2.2 Number of Nodes
4.2.3 CPU Name
4.2.4 Total Number of Processors
4.2.5 Total Number of Cores
4.2.6 Total Number of Threads
4.2.7 Total Physical Memory
4.2.8 Total number of memory DIMMs
4.2.9 Total Number of Storage Devices
4.3 Workload Efficiency Score / Workload DC Efficiency Score
4.4 Idle Watts
5. System Under Test
5.1 Shared Hardware
5.1.1 Enclosure
5.1.2 Form Factor
5.1.3 Server Blade Bays (populated / available)
5.1.4 Additional Hardware
5.1.5 Management Firmware Version
5.1.6 Power Supply Quantity (active / populated / bays)
5.1.7 Power Supply Details
5.1.8 Power Supply Operating Mode
5.1.9 Available Power Supply Modes
5.1.10 Network Switches (active / populated / bays)
5.1.11 Network Switch
5.2 Hardware per Node
5.2.1 Hardware Vendor
5.2.2 Model
5.2.3 Form Factor
5.2.4 CPU Name
5.2.5 CPU Frequency (MHz)
5.2.6 Number of CPU Sockets (populated / available)
5.2.7 CPU(s) Enabled
5.2.8 Number of NUMA Nodes
5.2.9 Hardware Threads / Core
5.2.10 Primary Cache
5.2.11 Secondary Cache
5.2.12 Tertiary Cache
5.2.13 Additional Cache
5.2.14 Additional CPU Characteristics
5.2.15 Total Memory Available to OS
5.2.16 Total Memory Amount (populated / maximum)
5.2.17 Total Memory Slots (populated / available)
5.2.18 Memory DIMMs
5.2.19 Memory Operating Mode
5.2.20 Power Supply Quantity (active / populated / bays)
5.2.21 Power Supply Details
5.2.22 Power Supply Operating Mode
5.2.23 Available Power Supply Modes
5.2.24 Disk Drive Bays (populated / available)
5.2.25 Disk Drive
5.2.26 Network Interface Cards
5.2.27 Management Controller or Service Processor
5.2.28 Expansion Slots (populated / available)
5.2.29 Optical Drives
5.2.30 Keyboard
5.2.31 Mouse
5.2.32 Monitor
5.2.33 Additional Hardware
5.3 Software per Node
5.3.1 Power Management
5.3.2 Operating System (OS)
5.3.3 OS Version
5.3.4 Filesystem
5.3.5 Other Software
5.3.6 Boot Firmware Version
5.3.7 Management Firmware Version
5.3.8 JVM Vendor
5.3.9 JVM Version
5.3.10 Client Configuration ID (formerly SERT Client Configuration)
6. System Under Test Notes
7. Details Report File
8. Worklet Summary
8.1 Worklet Result Chart
8.2 Result Table
8.2.1 Workload
8.2.2 Worklet
8.2.3 Normalized Peak Performance
8.2.4 Watts at Lowest Load Level
8.2.5 Watts at Highest Load Level
8.2.6 Geometric Mean of Normalized Performance
8.2.7 Geometric Mean of Power (Watts)
8.2.8 Worklet Efficiency Score / Worklet DC Efficiency Score
9. Measurement Devices
9.1 Power Analyzer
9.1.1 Hardware Vendor
9.1.2 Model
9.1.3 Serial Number
9.1.4 Connectivity
9.1.5 Input Connection
9.1.6 Metrology Institute
9.1.7 Calibration Laboratory
9.1.8 Calibration Label
9.1.9 Date of Calibration
9.1.10 PTDaemon® Version
9.1.11 Setup Description
9.2 Temperature Sensor
9.2.1 Hardware Vendor
9.2.2 Model
9.2.3 Driver Version
9.2.4 Connectivity
9.2.5 PTDaemon® Version
9.2.6 Sensor Placement
10. Aggregate Electrical and Environmental Data
10.1 Line Standard
10.2 Elevation (m)
10.3 Minimum Temperature (°C)
11. Worklet Performance and Power Details
11.1 Total Clients
11.2 CPU Threads per Client
11.3 Sample Client Command-line
11.4 Efficiency scores / DC Efficiency Scores
11.4.1 Load Level
11.4.2 Raw Performance Score
11.4.3 Normalized Performance Score
11.4.4 Average Active Power (W)
11.4.5 Load Level Efficiency Score / Load Level DC Efficiency Score
11.5 Performance Data
11.5.1 Phase
11.5.2 Interval
11.5.3 Actual Load
11.5.4 Score
11.5.5 Host CV
11.5.6 Client CV
11.5.7 Elapsed Measurement Time (s)
11.5.8 Transaction
11.5.9 Transaction Count
11.5.10 Transaction Time (S)
11.6 Power Data
11.6.1 Phase
11.6.2 Interval
11.6.3 Analyzer
11.6.4 Average Voltage (V)
11.6.5 Average Current (A)
11.6.6 Current Range Setting
11.6.7 Average Power Factor
11.6.8 Average Active Power (W)
11.6.9 Power Measurement Uncertainty (%)
11.6.10 Minimum Temperature (°C)
SPEC SERT is the next generation SPEC tool for evaluating the power and performance of server class computers.
The tool consists of several software modules:
These modules work together in real-time to collect server power consumption and performance data by exercising the System Under Test (SUT) with predefined workloads.
The test harness (called Chauffeur): handles the logistical side of measuring and recording power data along with controlling the software installed on the SUT and controller system itself.
The Director reads test parameters and environment description information from the SERT configuration files and controls the execution of the test based on this information. It is the central control instance of the SERT and communicates with the other software modules described below via TCP/IP protocol. It also collects the result data from the worklet instances and stores them in the basic result file "results.xml".
This module is the main SERT module on the System Under Test (SUT). It must be launched manually by the tester and it starts the client modules executing the workloads under control of the Director.
One or more client instances each executing its own Java Virtual Machine (JVM) are started by the Host for every worklet. Each Client executes worklet code to stress the SUT and reports the performance data back to the Director for each phase of the test.
The reporter gathers the configuration, environmental, power and performance data from the "results.xml" file after a run is complete and compiles it into HTML and text or CSV format result files. It will be started automatically by the Director after finishing all workloads to create the default set of report files. Alternately it can be started manually to generate special report files from the information in the basic result file "results.xml".
A Graphical User Interface (GUI) to facilitate configuration and setup of test runs, allows real-time monitoring of test runs and to review the results is part of the test package. The SERT GUI leads the user through the steps of detecting or entering the hardware and software configuration, setting up a trial run or a valid test, displaying results reports and other functions common to the testing environment.
The design goal for the SERT suite is to include all major aspects of server architecture, thus avoiding any preference for specific architectural features which might make a server look good under one workload and show disadvantages with another workload. The SERT workloads take advantage of different server capabilities by using various load patterns, which are intended to stress all major components of a server uniformly.
The SERT workloads consist of several different worklets, each stressing specific capabilities of a server. This approach furthermore supports generating individual efficiency scores for the different server components.
The worklets are built on synthetic tests which stress the different server components. Currently there are worklets for the following major server components:
For a detailed description of workloads and worklets please read the SERT Design Document.
The Power and Temperature Daemon (PTDaemon®) is a single executable program that communicates with a power analyzer or a temperature sensor via the server's native RS-232 port, USB port or additionally installed interface cards, e.g. GPIB. It reports the power consumption or temperature readings to the Director via a TCP/IP socket connection. It supports a variety of RS-232, GPIB and USB interface command sets for a variety of power analyzers and temperature sensors. PTDaemon is the only SERT software module that is not Java based. Although it can be quite easily setup and run on a server other than the controller, it will typically reside on the controller.
At the beginning of each run, the test configuration parameters are logged in order to be available for later conformance checks. Warnings are displayed for any non-compliant properties and printed in the final report; however, the test will run to completion, producing a report that is not valid for publication.
At the end of a test run the report generator module is called to generate the report files described here from the data given in the configuration files and collected during the test run. Basic validity checks are performed to ensure that interval length, target load throughput, temperature, etc. are within the defined limits. For more information see the section "Validation / Verification" in the SERT Design Document.
More detailed information can be found in the documents shown in the following table. For the latest versions, please consult SPEC's website.
| Run and Reporting Rules: | https://www.spec.org/sert2/SERT-runrules.pdf |
| User Guide: | https://www.spec.org/sert2/SERT-userguide.pdf |
| Design Document: | https://www.spec.org/sert2/SERT-designdocument.pdf |
| Measurement Setup Guide: | https://www.spec.org/power/docs/SPECpower-Measurement_Setup_Guide.pdf |
| Methodology: | https://www.spec.org/power/docs/SPECpower-Power_and_Performance_Methodology.pdf |
In this document all references to configurable parameters or result file fields are printed with different colors using the names from the configuration and result files:
Parameters from "test-environment.xml" are shown in red: <TestInformation><TestSponsor>
Parameters from "config-*.xml" or "*-configurations.xml" are shown in light purple: <suite><definitions><launch-definition><num-clients>
Parameters from "results.xml" are shown in green: <TestEnvironment><configuration><suite><client-configuration id>
The following configuration files are delivered with the test kit:
The authoritative versions of this file are located on the SPEC web site. For the current SERT version: https://www.spec.org/sert2/client-configurations-2.0.xml
A default version of this file is included in the SERT kit. The user must ensure that this local copy is up to date. If the local copy is outdated the latest version has to be downloaded from the SPEC web site location given above. The SERTUI provides support for downloading the current version of this file from the SPEC web site to the local SERT folder.
This section gives an overview of the information and result fields in the main report file "results.html/.txt".
The report file headline reads SERT® Report. Previous SERT releases supported a separate category of results for 32-bit environments. The report file headline for such 32-bit configurations showed the addendum: (32-bit category). 32-bit results are no longer supported by the current release.
The predefined default values of the parameters in the "test-environment.xml" file are intentionally incorrect. To highlight this, all parameters are defined with a leading underscore. The Reporter recognizes this and highlights these fields with a yellow background, except for the system name in the headline of the general information table.
The top bar gives general information regarding this test run.
The top bar header shows the name of the hardware vendor (see Hardware Vendor) plus the model name (see Model), potentially followed by a "(Historical System)" designation for systems which are no longer commercially available.
The name of the organization or individual that sponsored the test.
Generally, this is the name of the license holder.
<TestSponsor>
The date when all the software necessary to generate the result
is generally available.
<Software><Availability>
The date must be specified in the format: YYYY-MM
For example, if the operating system is available in 2017-02, but the JVM is not available until 2017-04, then the software availability date is 2017-04 (unless some other component pushes it out farther).
The name of the organization or individual that ran the test and submitted
the result.
<TestedBy>
The date when all the hardware and related firmware modules
necessary to generate the result are generally available.
<Hardware><Availability>
The date must be specified in the format: YYYY-MM
For example, if the CPU is available in 2017-02, but the Firmware version used for the test is not available until 2017-04, then the hardware availability date is 2017-04 (unless some other component pushes it out farther).
For systems which are no longer commercially available the original availability date must be specified here and the model name must be marked with the supplement "(Historical System)" (see Model).
Please see OSG Policy section 2.3.5 on SUT Availability for Historical Systems: https://www.spec.org/osg/policy.html#s2.3.5
The SPEC license number of the organization or individual that ran the
test.
<SpecLicense>
Single Supplier or Parts Built.
<SystemUnderTest><SystemSource>
The name of the city, state, and country the test took place. If there are
installations in multiple geographic locations, that must also be listed in
this field.
<Location>
The date on which the test for this result was performed. This information is provided automatically by the test software based on the timer function of the Controller system.
This field was introduced in SERT V2.0.0 and renamed to "SERT 2 Efficiency Score" in SERT V2.0.1.
It is intended for use in Energy Efficiency Regulatory Programs of government agencies around the world. This score is calculated as the weighted geometric mean of the individual workload efficiency scores of the CPU, Storage and Memory workloads (see also Workload Efficiency Score / Workload DC Efficiency Score).
In SERT 2.0.2 technical support for measuring DC powered servers was added. Efficiency scores from DC measurements are named "SERT 2 DC Efficiency Score" to distinguish them from AC based efficiency scores. DC efficiency scores are currently not allowed for official measurements in governmental Energy Efficiency Regulatory Programs. Therefore all DC results though technically correct are marked "INVALID".
Important note:
In SERT V2.0.0 the weighted geometric mean formula for calculating the composite efficiency score was using wrong weights of CPU and
Memory workload efficiency scores resulting in an incorrect SERT Efficiency Score being printed in SERT V2.0.0 result reports.
This problem was corrected in the SERT V2.0.1 release.
In order to distinguish old (incorrect) results from new (correct) results the score name has changed from "SERT Efficiency Score" to
"SERT 2 Efficiency Score".
Though the overall SERT efficiency score is incorrect in SERT V2.0.0 result reports the measured worklet and workload efficiency scores of this SERT version are correct. So existing SERT V2.0.0 results can be converted to valid SERT V2.0.1 results based on the measurement data in the "results.xml" file. There's no need to rerun measurements with the newer SERT V2.0.1 version.
SPEC provides a tool for this conversion process described here:
https://www.spec.org/sert2/sert_patches/sert-conversion.html
Follow the guidelines given on this web page for generating SERT V2.0.1 result reports from your existing SERT V2.0.0 "results.xml" file.
The tool converts an existing SERT V2.0.0 "results.xml" file to a new "results.updated.xml" file
including a corrected overall efficiency score.
Please note that the SERT version number in this file is set to 2.0.0.1 in order to distinguish updated results from native SERT V2.0.1 results.
Valid SERT V2.0.1 report files can then be generated from the "results.updated.xml" file following the instructions
in section 6.2 "Generate report files with the reporter scripts" of the SERT User Guide
A more detailed description of the SERT metric is given in the SERT Metric Document.
With SERT V2.0.0 an overall server efficiency score was introduced (see also SERT 2 Efficiency Score / SERT 2 DC Efficiency Score).
This chart was introduced in SERT V2.0.0.
A chart with a graphical representation of the individual workload and the overall server efficiency scores was added in this section.
Main attributes of the summary chart are:
Note: The scaling of the data range on the x-axis can be different depending on the maximum value to be displayed. Therefore individual summary charts from different SERT result reports may not be directly comparable.
Note: For invalid results the chart won't show any data.
Aggregated values for several system configuration parameters are reported in this table.
This field was introduced in SERT V2.0.0.
The model name identifying the system under test. The reported value is derived by the test software from the information given in the configuration files and by the test discovery scripts.
The total number of all nodes used for running the test. The reported values are calculated by the test software from the information given in the configuration files and by the test startup scripts.
This field was introduced in SERT V2.0.0.
Name of the tested CPU model. The reported value is derived by the test software from the information given in the configuration files and by the test discovery scripts.
The number of processor chips per node. For multi node results the total number of all chips used for running the test is added. The reported values are calculated by the test software from the information given in the configuration files and by the test discovery scripts.
The total number of all cores used for running the test. The reported value is calculated by the test software from the information given in the configuration files and by the test discovery scripts.
The total number of all hardware threads used for running the test. The reported value is calculated by the test software from the information given in the configuration files and by the test discovery scripts.
The total memory size for all systems used to run the test. The reported values are calculated by the test software from the information given in the configuration files and by the test discovery scripts.
This field was introduced in SERT V2.0.0.
The total number of DIMMs included in the tested SUT configuration. The reported value is calculated by the test software from the information given in the configuration files and by the test discovery scripts.
The total number of all storage devices used for running the test. The reported value is calculated by the test software from the information given in the configuration files and by the test discovery scripts.
The efficiency score for each workload is calculated from the efficiency scores of all its worklets as:
Geometric Mean (Efficiency ScoreWorklet 1...n)
Efficiency scores for the different workloads can be extremely dissimilar due to configuration varietes, which may be favorable for some workloads only, e.g. additional DIMMs for the Memory workload or disk drives for the Storage workload. Typically these changes wouldn't influence the CPU workload score perceivably (see also Worklet Efficiency Score / Worklet DC Efficiency Score).
In SERT 2.0.2 technical support for measuring DC powered servers was added. Workload efficiency scores from DC measurements are named "Workload DC Efficiency Score" to distinguish them from AC based workload efficiency scores. DC efficiency scores are currently not allowed for official measurements in governmental Energy Efficiency Regulatory Programs. Therefore all DC results though technically correct are marked "INVALID".
The average-watts measured for the Idle worklet test interval (see also Watts at Lowest Load Level). By definition there is no performance value for the Idle worklet and therefore also no efficiency score can be calculated.
The Idle power is NOT included in the efficiency score calculation of the 3 workloads.
The following section of the report file describes the hardware and the software of the System Under Test (SUT) used to generate the reported SERT results with the level of detail required to reproduce this result.
A table including the description of the shared hardware components.
This table will be printed for multi node results only and is not
included in single node report files.
The model name identifying the enclosure housing the tested nodes.
<SystemUnderTest><SharedHardware><Enclosure>
The full SUT form factor (including all nodes and any shared hardware).
<SystemUnderTest><SharedHardware><FormFactor>
For rack-mounted systems, specify the number of rack units. For other types of enclosures, specify "Tower" or "Other".
This field is divided into 2 parts separated by a slash. The first part
specifies the number of bays populated with a compute node or server blade.
The second part shows the number of available bays for server blades in the
enclosure.
<SystemUnderTest><SharedHardware><BladeBays><Populated>
<SystemUnderTest><SharedHardware><BladeBays><Available>
Any additional shared equipment added to improve performance and required to
achieve the reported scores.
<SharedHardware><Other><OtherHardware>
For each additional type of hardware component the quantity and a description need to be specified.
A version number or string identifying the management firmware running on
the SUT enclosure or "None" if no management controller was
installed.
<SharedHardware><Firmware><Management><Version>
This field is divided into 3 parts separated by slashes.
The first part shows the number of active power supplies, which might be
lower than the next number, if some power supplies are in standby mode and
used in case of failure only.
<SharedHardware><PowerSupplies><PowerSupply><Active>
The second part gives the number of bays populated with a power supply.
<SharedHardware><PowerSupplies><PowerSupply><Populated>
The third part describes the number of power supply bays available in the
SUT enclosure.
<SharedHardware><PowerSupplies><Bays>
The number and watts rating of this power supply unit (PSU) plus the supplier and the part number to identify it.
In the case of a "Parts Built" system (see:
System Source) the manufacturer name and the
part number of the PSU must be specified here.
<SharedHardware><PowerSupplies><PowerSupply><Active>
<SharedHardware><PowerSupplies><PowerSupply><RatingInWatts>
<SharedHardware><PowerSupplies><PowerSupply><Description>
There may be multiple lines in this field if different types of PSUs have been used for this test, one for each PSU type.
Power supply unit (PSU) operating mode active for running this test. Must be
one of the available modes as described in the field
Available Power Supply Modes.
<SharedHardware><PowerSupplies><OperatingMode>
The available power supply unit (PSU) modes depend on the capabilities of
the tested server hardware and firmware.
<SharedHardware><PowerSupplies><AvailableModes><Mode>
Typical power supply modes are:
For example: 2 + 1 Spare PSU
Two PSUs are active, the third PSU is inactive in Standby mode. System operation is guaranteed for 1 PSU fail in case of 3 PSUs in total.
For example: 2 + 2 (2 AC sources)
2 PSUs are active, the other two PSUs are inactive in Standby mode. 2 of the 4 PSUs are each connected to a separate AC source. This ensures that the system can continue operation even if a power line or a single PSU fails.
This field is divided into 3 parts separated by slashes.
The first part shows the number of active network switches, which might be
lower than the next number, if some network switches are in standby mode and
not used for running the test.
<SharedHardware><NetworkSwitches><NetworkSwitch><Active>
The second part gives the number of bays populated with a network
switch.
<SharedHardware><NetworkSwitches><NetworkSwitch><Populated>
The third part describes the number of network switch bays available in the
SUT enclosure.
<SharedHardware><NetworkSwitches><Bays>
"N/A" if no network switch was used.
The number, a description (manufacturer and model name), and details
(special settings, etc.) of the network switch(es) used for this
test.
<SharedHardware><NetworkSwitches><NetworkSwitch><Active>
<SharedHardware><NetworkSwitches><NetworkSwitch><Description>,
"N/A" if no network switch was used.
<SharedHardware><NetworkSwitches><NetworkSwitch><Details>
This section describes in detail the different hardware components of the system under test which are important to achieve the reported result.
Company which sells the hardware.
<SystemUnderTest><Node><Hardware><Vendor>
The model name identifying the system under test.
<SystemUnderTest><Node><Hardware><Model>
Systems which are no longer commercially available should be marked with the
supplement "(Historical System)".
<SystemUnderTest><Node><Hardware><Historical>
Please see OSG Policy section 2.3.5 on SUT Availability for Historical Systems https://www.spec.org/osg/policy.html#s2.3.5.
The form factor for this system.
<SystemUnderTest><Node><Hardware><FormFactor>
In multi-node configurations, this is the form factor for a single node. For rack-mounted systems, specify the number of rack units. For blades, specify "Blade". For other types of systems, specify "Tower" or "Other".
A manufacturer-determined processor formal name.
<SystemUnderTest><Node><Hardware><CPU><Name>
Trademark or copyright characters must not be included in this string. No additional information is allowed here, e.g. turbo boost frequency or hardware threads.
Examples:
The nominal (marked) clock frequency of the CPU, expressed in
megahertz.
<SystemUnderTest><Node><Hardware><CPU><FrequencyMHz>
If the CPU is capable of automatically running the processor core(s) faster
than the nominal frequency and this feature is enabled, then this additional
information must be listed here, at least the maximum frequency and the use
of this feature.
<SystemUnderTest><Node><Hardware><CPU><TurboFrequencyMHz>
<SystemUnderTest><Node><Hardware><CPU><TurboMode>
Furthermore if the enabled/disabled status of this feature is changed from
the default setting this must be documented in the
System Under Test Notes field.
<SystemUnderTest><Notes><Note>
Example:
This field is divided into 2 parts separated by a slash. The first part
gives the number of sockets populated with a CPU chip as used for this SERT
result and the second part the number of available CPU sockets.
<SystemUnderTest><Node><Hardware><CPU><PopulatedSockets>
<SystemUnderTest><Node><Hardware><AvailableSockets>
The CPUs that were enabled and active during the test run, displayed as the
number of cores, number of processors, and the number of cores per
processor.
<SystemUnderTest><Node><Hardware><CPU><Cores>
<SystemUnderTest><Node><Hardware><CPU><PopulatedSockets>
<SystemUnderTest><Node><Hardware><CPU><CoresPerChip>
The number of Non-Uniform Memory Access (NUMA) nodes used for this SERT
test. Typically this is equal to the number of populated sockets times 1 or
2 depending on the CPU architecture.
<SystemUnderTest><Node><Hardware><NumaNodes>
The total number of active hardware threads for this SERT test and the
number of hardware threads per core given in parentheses.
<SystemUnderTest><Node><Hardware><CPU><HardwareThreadsPerCore>
Description (size and organization) of the CPU's primary cache. This cache
is also referred to as "L1 cache".
<SystemUnderTest><Node><Hardware><CPU><Cache><Primary>
Description (size and organization) of the CPU's secondary cache. This cache
is also referred to as "L2 cache".
<SystemUnderTest><Node><Hardware><CPU><Cache><Secondary>
Description (size and organization) of the CPU's tertiary, or "L3"
cache.
<SystemUnderTest><Node><Hardware><CPU><Cache><Tertiary>
Description (size and organization) of any other levels of cache
memory.
<SystemUnderTest><Node><Hardware><CPU><Cache><Other>
Additional technical characteristics to help identify the processor.
<SystemUnderTest><Node><Hardware><CPU><OtherCharacteristics>
Total memory capacity in GB available to the operating system for task processing. This number is typically slightly lower then the amount of configured physical memory. It is determined automatically by the SERT discovery tools.
For multi-node runs, this is the average memory reported by each host. Prior to SERT 1.1.1 it was the sum of the memory across all hosts.
This field is divided into 2 parts separated by a slash. The first part
describes the amount of installed physical memory in GB as used for this
SERT test. The second number gives the maximum possible memory capacity in
GB if all memory slots are populated with the highest capacity DIMMs
available in the SUT.
<SystemUnderTest><Node><Hardware><Memory><SizeMB>
<SystemUnderTest><Node><Hardware><Memory><MaximumSizeMB>
This field is divided into 2 parts separated by a slash. The first part
describes the number of memory slots populated with a memory module as used
for this SERT test. The second part shows the total number of available
memory slots in the SUT.
<SystemUnderTest><Node><Hardware><Memory><Dimms><Quantity>
<SystemUnderTest><Node><Hardware><Memory><AvailableSlots>
Detailed description of the system main memory technology, sufficient for
identifying the memory used in this test.
<SystemUnderTest><Node><Hardware><Memory><Dimms><Quantity>
<SystemUnderTest><Node><Hardware><Memory><Dimms><DimmSizeMB>
<SystemUnderTest><Node><Hardware><Memory><Dimms><Description>
There may be multiple instances of this field if different types of DIMMs have been used for this test, one separate field for each DIMM type.
If memory modules using other technologies have been installed, e.g. High Bandwidth Memory (HBM), the above fields should be used to report the number and size of these modules. The description field should include a precise name of the memory module explicitly identifying the memory technology and memory module parameters being used. There's no predefined format for non DDR memory module description.
Since the introduction of DDR4 memory there are two slightly different formats. The recommended formats are described here.
DDR4 Format:
N x gg ss pheRxff PC4v-wwwwaa-m; slots k, ... l populated
References:
For example:
8 x 16 GB 2Rx4 PC4-2133P-R; slots 1 - 8 populated
Where:
Note: The main string "gg ss pheRxff PC4v-wwwwaa-m" can be read directly from the label on the memory module itself for all vendors who use JEDEC standard labels.
DDR3 Format:
N x gg ss eRxff PChv-wwwwwm-aa, ECC CLa; slots k, ... l populated
Reference:
For example:
8 x 8 GB 2Rx4 PC3L-12800R-11, ECC CL10; slots 1 - 8 populated
Where:
Description of the memory operating mode. Examples of possible values are:
Standard, Mirror, Spare, Independent
<SystemUnderTest><Node><Hardware><Memory><OperatingMode>
This field is divided into 3 parts separated by slashes. The first part
shows the number of active power supplies, which might be lower than the
next number, if some power supplies are in standby mode and used in case of
failure only. The second part gives the number of bays populated with a
power supply. The third part describes the number of power supply bays
available in this node.
<SystemUnderTest><Node><Hardware><PowerSupplies><PowerSupply><Active>
<SystemUnderTest><Node><Hardware><PowerSupplies><PowerSupply><Populated>
<SystemUnderTest><Node><Hardware><PowerSupplies><Bays>
All three parts can can show "None" if the node is powered by a shared power supply.
The number and watts rating of this power supply unit (PSU) plus the supplier name and the order number to identify it.
In case of a "Parts Built" system (see
System Source) the manufacturer and the part
number of the PSU must be specified here.
<SystemUnderTest><Node><Hardware><PowerSupplies><PowerSupply><Active>
<SystemUnderTest><Node><Hardware><PowerSupplies><PowerSupply><RatingInWatts>
<SystemUnderTest><Node><Hardware><PowerSupplies><PowerSupply><Description>
There may be multiple lines in this field if different types of PSUs have been used for this test, one for each PSU type.
"N/A" if this node does not include a power supply.
Operating mode active for running this test. Must be one of the available
modes as described in the field Available Power
Supply Modes.
<SystemUnderTest><Node><Hardware><PowerSupplies><OperatingMode>
The available power supply unit (PSU) modes depend on the capabilities of
the tested server hardware and firmware.
<SystemUnderTest><Node><Hardware><PowerSupplies><AvailableModes>
Typical power supply modes are:
For example: 2 + 1 Spare PSU
Two PSUs are active, the third PSU is inactive in Standby mode. System operation is guaranteed for 1 PSU fail in case of 3 PSUs in total.
For example: 2 + 2 (2 AC sources)
2 PSUs are active, the other two PSUs are inactive in Standby mode. 2 of the 4 PSUs are each connected to a separate AC source. This ensures that the system can continue operation even if a power line or a single PSU fails.
This field is divided into 2 parts separated by a slash. The first part
gives the number of disk drive bays actually populated with a disk drive for
this SERT test. The second part shows the number of available drive bays in
the SUT, some of which may have been empty in the tested configuration.
<SystemUnderTest><Node><Hardware><DiskDrives><DiskGroup><Quantity>
<SystemUnderTest><Node><Hardware><DiskDrives><Bays>
Disk drives may be of different type in heterogenous multi disk configurations. In this case separate Disk Drive fields need to be specified for each type, describing its capabilities.
This field contains four rows. In case of heterogenous multi disk configurations there may be several instances of this field.
This field contains three rows. In case of heterogenous configurations with different Network Interface Cards (NICs) there may be several instances of this field.
Specifies whether any management controller was configured in the SUT.
<SystemUnderTest><Node><Hardware><ManagementController><Quantity>
This field is divided into 2 parts separated by a slash. There may be multiple lines in this field if different types of expansion slots are available, one for each slot type.
The first part gives the number of expansion slots (PCI slots) actually
populated with a card for this SERT test. The second part shows the number
of available expansion slots in the SUT; some of them may have been empty in
the tested configuration.
<SystemUnderTest><Node><Hardware><ExpansionSlots><ExpansionSlot><Populated>
<SystemUnderTest><Node><Hardware><ExpansionSlots><ExpansionSlot><Quantity>
Specifies whether any optical drives were configured in the SUT.
<SystemUnderTest><Node><Hardware><OpticalDrives>
The type of keyboard (USB, PS2, KVM or None) used.
<SystemUnderTest><Node><Hardware><Keyboard>
The type of mouse (USB, PS2, KVM or None) used.
<SystemUnderTest><Node><Hardware><Mouse>
Specifies if a monitor was used for the test and how it was connected
(directly or via KVM).
<SystemUnderTest><Node><Hardware><Monitor>
Number and description of any additional equipment added to improve
performance and required to achieve the reported scores.
<SystemUnderTest><Node><Hardware><Other><OtherHardware><Quantity>
<SystemUnderTest><Node><Hardware><Other><OtherHardware><Description>
This section describes in detail the various software components installed on the system under test, which are critical to achieve the reported result, and their configuration parameters.
This field shows whether power management features of the SUT were enabled
or disabled.
<SystemUnderTest><Node><Software><OperatingSystem><PowerManagement>
Operating system vendor and name.
<SystemUnderTest><Node><Software><OperatingSystem><Vendor>
<SystemUnderTest><Node><Software><OperatingSystem><Name>
Examples:
The operating system version. For Unix based operating systems the detailed
kernel number must be given here. If there are patches applied that affect
performance and / or power, they must be disclosed in the
System Under Test Notes.
<SystemUnderTest><Node><Software><OperatingSystem><Version>
Examples:
The type of the filesystem containing the operating system files and
directories and test files for the storage worklets.
<SystemUnderTest><Node><Software><OperatingSystem><FileSystem>
Any performance- and/or power-relevant software used and required to
reproduce the reported scores, including third-party libraries,
accelerators, etc.
<SystemUnderTest><Node><Software><Other><OtherSoftware>
A version number or string identifying the boot firmware installed on the
SUT.
<SystemUnderTest><Node><Firmware><Boot><Version>
A version number or string identifying the management firmware running on
the SUT or "None" if no management controller was installed.
<SystemUnderTest><Node><Firmware><Management><Version>
The company that makes the JVM software.
<SystemUnderTest><Node><JVM><Vendor>
Name and version of the JVM software product, as displayed by the
"java -version" or "java -fullversion"
commands.
<SystemUnderTest><Node><JVM><Version>
Examples:
Beginning with SERT V1.0.1 this field shows the label of the client configuration element from the "client-configurations-N.N.xml" file specifying the predefined set of JVM options and number of clients to be used for running the tests.
A default version of this file is included in the SERT kit. The user has to
ensure that this local copy is up to date compared to the master copy of
this file available at:
https://www.spec.org/sert2/client-configurations-2.0.xml
If the local copy is outdated the latest version has to be downloaded from the SPEC web site location given above.
The correct option set for the given configuration is largely determined automatically by SERTUI based on the configuration parameters detected by the hardware discovery scripts. It's strongly recommended to manually check the detected parameters and the automatically selected option set for correctness.
If the SERT is started from command line the correct JVM option set for the
given configuration must be specified manually in the
"config-all.xml" file.
<suite><definitions><option-set><parameter>
The content displayed here is taken from the "results.xml"
file generated during the test run.
<TestEnvironment><configuration><suite><client-configuration id>
Free text description of what sort of tuning one has to do to the SUT to get
these results. Also additional hardware information not covered in the other
fields above can be given here.
<SystemUnderTest><Node><Notes>
The following list shows examples of information that must be reported in this section:
Note: Disabling of OS services is disallowed (see section 2.4.5 "Software" of the SERT Run and Reporting Rules), and will invalidate the result.
The details report file "results-details.html/.txt" is created together with the standard report file at the end of each successful SERT run. In addition to the information in the standard report file described above it includes more detailed performance and power result values for each individual worklet.
This section describes the main results for all worklets in a table and as a graph. It is included in the details report file "results-details.html/.txt" only.
The worklet result chart graphically displays the power, performance and efficiency scores for the different worklets. Each worklet is presented on a separate row beginning with the worklet name on the left. The lines are printed with distinct background colors for the different workloads:
The result chart is divided in three sections.
For results marked "INVALID" this section remains empty, i.e. no efficiency score ranges are displayed.
In SERT 2.0.2 technical support for measuring DC powered servers was added. Efficiency scores from DC measurements are named "DC Efficiency Score" to distinguish them from AC based efficiency scores. DC efficiency scores are currently not allowed for official measurements in governmental Energy Efficiency Regulatory Programs. Therefore all DC results though technically correct are marked "INVALID".
The result table numerically displays the power, performance and efficiency scores for the different worklets. Each worklet is presented on a separate row.
This column of the result table shows the names of the workloads. A workload may include one or more worklets.
This column of the result table shows the names of the worklets the following values are belonging to.
In order to get performance values in the same order of magnitude from all worklets the individual performance scores of each worklet (see Score) are divided by a fixed reference score. The reference score for each worklet was determined taking the average performance score over several SERT test runs on a well defined reference configuration under different operating systems.
The fields in this column show the normalized performance for the Peak Interval of each worklet only. The values are calculated by taking the Peak Interval performance score and dividing it by the corresponding reference score for that worklet.
This column of the result table shows the worklet power readings at the lowest load level. Please note that this does not correspond to "Idle", which is implemented as a separate workload in SERT and not included in each worklet.
This column of the result table shows the worklet power readings at the highest load level, or "100%" load.
This column was removed in SERT V2.0.1. Detailed performance information for all worklet measurement intervals is now listed in the worklet specific Efficiency Scores / DC Efficiency Scores tables (see Normalized Performance Score).
The worklet performance score is calculated as the geometric mean of the normalized performance scores over all measurement intervals of a worklet.
In order to get performance values in the same order of magnitude from all worklets the individual performance scores for each measurement interval of all worklets (see Score), are divided by a fixed reference score. The reference score for each worklet was determined taking the average performance score over several SERT test runs on a well defined reference configuration under different operating systems.
A detailed description of the normalization process is given in chapter 5.1 "The SERT Efficiency Metric" of the SERT Design Document.
This column was removed in SERT V2.0.1. Detailed power information for all worklet measurement intervals is now listed in the worklet specific Efficiency Scores / DC Efficiency Scores tables (see Average Active Power (W)).
The geometric mean of the average-watts over all measurement intervals (see Average Active Power (W) in the "Worklet Performance and Power Details" section).
The following formula is used to calculate the worklet efficiency scores for the current SERT version.
Worklet Efficiency Score = 1000 * Geometric Mean (EfficiencyInterval 1...n)
Efficiency for the Idle worklet is marked as not applicable (n/a) because the performance part is missing by definition.
Please note that Idle power is NOT included in the per worklet efficiency score calculation.
In SERT 2.0.2 technical support for measuring DC powered servers was added. Worklet efficiency scores from DC measurements are named "Worklet DC Efficiency Score" to distinguish them from AC based worklet efficiency scores. DC efficiency scores are currently not allowed for official measurements in governmental Energy Efficiency Regulatory Programs. Therefore all DC results though technically correct are marked "INVALID".
This report section is available in the Details Report File "results-details.html/.txt" only. It shows the details of the different measurement devices used for this test run.
There may be more than one measurement device used to measure power and temperature. Each of them will be described in a separate table.
The following table includes information about the power analyzer
identified by "Name" and used to measure the electrical
data.
<SystemUnderTest><MeasurementDevices><PowerAnalyzer><Identifier>
Company which manufactures and/or sells the power analyzer.
<SystemUnderTest><MeasurementDevices><PowerAnalyzer><HardwareVendor>
The model name of the power analyzer type used for this test run.
<SystemUnderTest><MeasurementDevices><PowerAnalyzer><Model>
The serial number uniquely identifying the power analyzer used for this test
run.
<SystemUnderTest><MeasurementDevices><PowerAnalyzer><SerialNumber>
Which interface was used to connect the power analyzer to the PTDaemon host
system and to read the power data, e.g. RS-232 (serial port), USB, GPIB, IP,
etc.
<SystemUnderTest><MeasurementDevices><PowerAnalyzer><Connectivity>
Input connection used to connect the load, if several options are available,
or "Default" if not.
<SystemUnderTest><MeasurementDevices><PowerAnalyzer><InputConnection>
Name of the national metrology institute, which specifies the calibration
standards for power analyzers, appropriate for the
Test Location reported in the result files.
<SystemUnderTest><MeasurementDevices><PowerAnalyzer><CalibrationInstitute>
Calibration should be done according to the standard of the country where the test was performed or where the power analyzer was manufactured.
Examples:
| Country | Metrology Institute |
|---|---|
| China | NIM (National Institute of Metrology) |
| Germany | PTB (Physikalisch Technische Bundesanstalt) |
| Japan | AIST (National Institute of Advanced Industrial Science and Technology) |
| Taiwan (ROC) | ITRI (Industrial Technology Research Institute) |
| USA | NIST (National Institute of Standards and Technology) |
A list of national metrology institutes for many countries is maintained by NIST at https://www.nist.gov/iaao/national-metrology-laboratories.
Name of the organization that performed the power analyzer calibration
according to the standards defined by the national metrology institute.
This could be the analyzer manufacturer, a third party company, or an
organization within your own company.
<SystemUnderTest><MeasurementDevices><PowerAnalyzer><AccreditedBy>
A number or character string which uniquely identifies this meter
calibration event. May appear on the calibration certificate or on a sticker
applied to the power analyzer. The format of this number is specified by the
organization performing the calibration.
<SystemUnderTest><MeasurementDevices><PowerAnalyzer><CalibrationLabel>
The date (yyyy-mm-dd) the calibration certificate was issued, from the
calibration label or the calibration certificate.
<SystemUnderTest><MeasurementDevices><PowerAnalyzer><DateOfCalibration>
The version of the power daemon program reading the analyzer data, including CRC information to verify that the released version was running unchanged. This information is provided automatically by the test software.
Free format textual description of the device or devices measured by this
power analyzer and the accompanying PTDaemon instance, e.g. "SUT Power
Supplies 1 and 2".
<SystemUnderTest><MeasurementDevices><PowerAnalyzer><SetupDescription>
The following table includes information about the temperature sensor identified
by "Name" and used to measure the ambient temperature of the test environment.
<SystemUnderTest><MeasurementDevices><TemperatureSensor><Identifier>
Company which manufactures and/or sells the temperature sensor.
<SystemUnderTest><MeasurementDevices><TemperatureSensor><HardwareVendor>
The manufacturer and model name of the temperature sensor used for this
test run.
<SystemUnderTest><MeasurementDevices><TemperatureSensor><Model>
The version number of the operating system driver used to control and read
the temperature sensor.
<SystemUnderTest><MeasurementDevices><TemperatureSensor><DriverVersion>
Which interface was used to read the temperature data from the sensor, e.g.
RS-232 (serial port), USB, etc.
<SystemUnderTest><MeasurementDevices><TemperatureSensor><Connectivity>
The version of the power daemon program reading the analyzer data, including CRC information to verify that the released version was running unchanged. This information is provided automatically by the test software.
Free format textual description of the device or devices measured and the
approximate location of this temperature sensor, e.g. "50 mm in front
of SUT main airflow intake".
<SystemUnderTest><MeasurementDevices><TemperatureSensor><SetupDescription>
The following section displays more details of the electrical and environmental data collected during the different target loads, including data not used to calculate the test result. For further explanation of the measured values look in the "SPECpower Methodology" document (SPECpower-Power_and_Performance_Methodology.pdf).
Description of the line standards for the main AC power as provided by the
local utility company and used to power the SUT. The standard voltage and
frequency are printed in this field followed by the number of phases and
wires used to connect the SUT to the AC power line.
<SystemUnderTest><LineStandard><Voltage>
<SystemUnderTest><LineStandard><Frequency>
<SystemUnderTest><LineStandard><Phase>
<SystemUnderTest><LineStandard><Wires>
Elevation of the location where the test was run. This information is
provided by the tester.
<SystemUnderTest><TestInformation><ElevationMeters>
Minimum temperature which was measured by the temperature sensor during all target load levels.
This report section is available in the Details Report File "results-details.html/.txt" only. It is divided into separate segments for all worklets each starting with a title bar showing the workload and worklet names <workload name>: <worklet name>. Each segment includes Performance and Power Data tables together with some details about the client JVMs for the corresponding worklet.
Total number of client JVMs started on the System Under Test for this worklet.
Beginning with SERT V1.0.2 this number is calculated by the SERT code based on the information specified in the "client-configurations-N.N.xml" file. See Client Configuration ID for more details.
The number of hardware threads each instance of the client JVM is affinitized to.
The complete command-line for one of the client JVMs used to run this worklet, including affinity specification, the Java classpath, the JVM tuning flags and additional SERT parameters. The affinity mask, the "Client N of M" string and the "-jvmid N" parameter printed here are valid for one specific instance of the client JVM only. The other client JVMs will use their associated affinity masks, strings and parameters but share the rest of the commandline.
Beginning with SERT V1.0.2 the JVM tuning flags are included automatically by the SERT code based on the information specified in the "client-configurations-N.N.xml" file. See Client Configuration ID for more details.
This table was introduced in SERT V2.0.1.
The table presents detailed performance scores and power data for each measurement interval of this worklet together with the corresponding interval efficiency scores. In the last row of the table the aggregate performance and power values plus the worklet efficiency score calculated from them are displayed.
In SERT 2.0.2 technical support for measuring DC powered servers was added. Efficiency scores from DC measurements are named "DC Efficiency Scores" to distinguish them from AC based efficiency scores. DC efficiency scores are currently not allowed for official measurements in governmental Energy Efficiency Regulatory Programs. Therefore all DC results though technically correct are marked "INVALID".
The target load level percentage for each measurement interval of this worklet
is printed in a separate row.
Note: Only the measurement intervals are listed here.
The name of the current worklet is repeated in the bottom field of this column.
In this column the raw (measured) performance score for each measurement target load level is printed.
These fields correspond to the measurement fields of the Score column
in the Performance Data table below.
The normalized performance score values for each measurement load level are calculated by taking the interval Raw Performance Score and dividing it by the corresponding reference score for that worklet interval. The reference score for each worklet interval was determined taking the average performance score over several SERT test runs on a well defined reference configuration under different operating systems.
The bottom field shows the geometric mean calculated from the normalized performance scores of all measurement load levels above.
Average active power in Watts for each measurement interval as measured by the power analyzer(s) connected to the system under test and reported by the corresponding PTDaemon instance(s).
These fields typically correspond to the measurement fields of the Average Active Power (W) column in the Power Data table below.
The bottom field shows the geometric mean calculated from the average active power values of all measurement load levels above.
Each field of this column displays the interval efficiency score for the given target load level calculated from the Normalized Performance Score divided by the corresponding Average Active Power (W) value times 1000.
The bottom field shows the Worklet efficiency score calculated as the geometric mean of the efficiency scores of all its intervals (see also Worklet Efficiency Score / Worklet DC Efficiency Score).
In SERT 2.0.2 technical support for measuring DC powered servers was added. Load level efficiency scores from DC measurements are named "Load Level DC Efficiency Score" to distinguish them from AC based load level efficiency scores. DC efficiency scores are currently not allowed for official measurements in governmental Energy Efficiency Regulatory Programs. Therefore all DC results though technically correct are marked "INVALID".
This table displays detailed performance information for a worklet. The information is presented on separate rows per Phase, Interval and Transaction where applicable.
This column of the performance data table shows the phase names for the performance values presented in the following columns of the rows belonging to this phase.
Examples of phases are "Warmup", "Calibration" and "Measurement".
This column of the performance data table shows the interval names for the performance values presented in the following columns of the rows belonging to this interval.
Examples of intervals are "max" and "75%".
The "Actual Load" is calculated by dividing the interval "Score" by the "Calibration Result". This value is shown for the measurement intervals only. It can be compared against the target load level as defined by the "Interval" name.
The fields in this column show the worklet specific total score for each interval, which is the sum of the scores from all client JVMs. The individual client JVM scores are calculated separately for each client JVM dividing the specific transaction count by associated elapsed time for this interval. Individual client JVM scores are not shown in the results report.
The elapsed time of each JVM which is used to calculate the "Score" will generally be slightly shorter than the Elapsed Measurement Time for this interval printed in the results report. Therefore "Score" calculation from the reported Transaction Count and Elapsed Measurement Time values is not exactly matching the shown "Score" value.
For the calibration intervals a field showing the "Calibration Result" score is added in this column.
In contrast to the worklet performance score given in the performance data table Result Table above this score isn't normalized.
Note that elapsed interval time is the wall clock time specified in the SERT configuration file "config-all.xml" -- not the Transaction Time from the report.
The memory worklets (Flood3 and Capacity3) have their own score calculations that include other factors, e.g. memory capacity. A detailed description is given in the SERT Design Document https://www.spec.org/sert/SERT-designdocument.pdf.
With SERT release 2.0.0 the algorithm to calculate memory worklet scores has changed again. Therefore memory worklet scores from previous SERT releases are no longer comparable to those from SERT 2.0.0 and newer releases.
This field was introduced in SERT V1.1.0.
The host CV (coefficient of variation) is calculated from all individual node performance "Scores" (Score) for the whole set of nodes (population). Individual CVs are shown in this column for each interval. Real values are calculated and displayed for multi node runs only. For single node runs "0.0%" is printed in all fields of this column.
The coefficient of variation (CV) is defined as the ratio of the standard deviation σ to the mean μ:
cv = σ ⁄ μ
It represents the extent of variability in relation to mean of the population. The calculated values are presented as percentage numbers in the SERT report files.
The Host CV is used by SERT to identify significant deviance of results of some nodes from the mean. Similar results per node are expected for a homogeneous set of nodes, i.e. the CV should be fairly small. High CV values indicate greatly different results for one or more nodes. CV values above certain thresholds will cause warnings or error messages being printed in the SERT result files.
This field was introduced in SERT V1.1.0.
The Client CV (coefficient of variation) is calculated from all individual client performance "Scores" (Score) for the whole set of clients (JVM instances) including all nodes for multi node runs (population). Individual CVs are shown in this column for each interval.
The coefficient of variation (CV) is defined as the ratio of the standard deviation σ to the mean μ:
cv = σ ⁄ μ
It represents the extent of variability in relation to mean of the population. The calculated values are presented as percentage numbers in the SERT report files.
The Client CV is used by SERT to identify significant deviance of results of some clients from the mean. Typically similar results per client are expected, i.e. the CV should be fairly small. High CV values indicate greatly different results for one or more clients. For unbalanced configurations, e.g. different types of storage devices (HDD and SSD) or dissimilar amounts of memory attached to different processors, high CV values are "normal". CV values above certain thresholds will cause warnings or error messages being printed in the SERT result files. Warnings can be ignored for unbalanced configurations as high CV values are expected in this case.
The time spent during this interval executing transactions. Usually multiple client JVMs are executing worklet transactions. The "Elapsed Measurement Time" is calculated subtracting the earliest start time from the latest end time of any client JVM.
The "Elapsed Measurement Time" will generally be slightly longer than the elapsed time of each JVM which is used to calculate the Score for this interval.
This time typically doesn't match exactly the interval time specified in the SERT configuration file "config-all.xml".
The name of the transaction(s) related to the following "Transaction Count" and "Transaction Time" values.
Some worklets execute only one type of transaction whereas others, e.g. CPU: SSJ, run several different transactions. There will be a separate line for each transaction.
The total number of successfully completed transactions defined in column "Transaction" during the interval given in column "Interval". This number is calculated summing up completed transactions of all client JVMs
For worklets including multiple transaction types a "sum" field is added, showing the aggregated transaction count for all transactions of this worklet.
The total elapsed (wall clock) time spent executing this transaction during this interval. It only includes the actual execution time, and not input generation time. Since multiple transactions execute concurrently in different threads, this time may be longer than the length of the interval.
For worklets including multiple transaction types a "sum" field is added, showing the aggregated transaction time for all transactions of this worklet.
This table displays detailed power information for a worklet. The information is presented on separate rows per Phase and Interval. There will be separate power data tables for each power analyzer.
This column of the power data table gives the phase names for the power values presented in the following fields of the rows belonging to this phase.
The "Sum" field identifies the summary row for all measurement intervals (see Average Active Power (W)).
This column of the power data table gives the interval names for the power values presented in the following fields of the rows belonging to this interval.
The "Total" field identifies the summary row for all power analyzers (see Average Active Power (W)).
Name identifying the power analyzer whose power readings are displayed in this table. More details regarding this power analyzer are given in the Power Analyzer table(s) in the "Measurement Devices" section above.
Average voltage in Volts for each interval as reported by the PTDaemon instance connected to this power analyzer.
Average current in Amps for each interval as reported by the PTDaemon instance connected to this power analyzer.
The current range for each test phase as configured in the power analyzer. Typically range settings are read by PTDaemon directly from the power analyzer.
Please note that automatic current range setting by the analyzer is not allowed for all currently accepted analyzers and will invalidate the result.
Average power factor for each interval as reported by the PTDaemon instance connected to this power analyzer.
Average active power in Watts for each interval as reported by the PTDaemon instance connected to this power analyzer.
In this column a "Sum""Total" field is added, showing the aggregated active power for all measurement intervals over all power analyzers.
The average uncertainty of the reported power readings for each test phase as calculated by PTDaemon based on the range settings. The value must be within the 1% limit defined in section "2.6 Validity Checks - PowerUncertaintyReadingsValidator" of the SERT Run and Reporting Rules document.
For some analyzers range reading may not be supported. The uncertainty calculation may still be possible based on manual or command line range settings. More details are given in the measurement setup guide (see SPECpower_Measurement_Setup_Guide.pdf).
The minimum ambient temperature for each interval as measured by the temperature sensor. All values are measured in ten second intervals, evaluated by the PTDaemon and reported to the test harness at the end of each interval.
Copyright © 2006-2022 Standard Performance Evaluation Corporation
All Rights Reserved