(To check for possible updates to this document, please see http://www.spec.org/sert/docs/SERT-Result_File_Fields.html)

Overview

Selecting one of the following will take you to the detailed table of contents for that section:

1. SPEC SERT

2. Main Report File

3. Top Bar

4. Summary

5. Worklet Summary

6. Aggregate SUT Data

7. System Under Test

8. SUT Notes

9. Aggregate Electrical and Environmental Data

10. Details Report

11. Measurement Devices

12. Worklet Performance and Power Details

Detailed Contents

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

4. Summary

4.1 Workload Efficiency Score

4.2 Idle Watts

5. Worklet Summary

5.1 Result Chart

5.2 Result Table

5.2.1 Workload

5.2.2 Worklet

5.2.3 Normalized Peak Performance

5.2.4 Watts at Lowest Load Level

5.2.5 Watts at Highest Load Level

5.2.6 ∑ Normalized Performance

5.2.7 ∑ Power (Watts)

5.2.8 Efficiency Score

6. Aggregate SUT Data

6.1 # of Nodes

6.2 # of Processors

6.3 Total Physical Memory

6.4 # of Cores

6.5 # of Storage Devices

6.6 # of Threads

7. System Under Test

7.1 Shared Hardware

7.1.1 Enclosure

7.1.2 Form Factor

7.1.3 Server Blade Bays (populated / available)

7.1.4 Additional Hardware

7.1.5 Management Firmware Version

7.1.6 Power Supply Quantity (active / populated / bays)

7.1.7 Power Supply Details

7.1.8 Power Supply Operating Mode

7.1.9 Available Power Supply Modes

7.1.10 Network Switches (active / populated / bays)

7.1.11 Network Switch

7.2 Hardware per Node

7.2.1 Hardware Vendor

7.2.2 Model

7.2.3 Form Factor

7.2.4 CPU Name

7.2.5 CPU Frequency (MHz)

7.2.6 Number of CPU Sockets (available / populated)

7.2.7 CPU(s) Enabled

7.2.8 Number of NUMA Nodes

7.2.9 Hardware Threads / Core

7.2.10 Primary Cache

7.2.11 Secondary Cache

7.2.12 Tertiary Cache

7.2.13 Other Cache

7.2.14 Additional CPU Characteristics

7.2.15 Total Memory Available to OS

7.2.16 Total Memory Amount (populated / maximum)

7.2.17 Total Memory Slots (populated / available)

7.2.18 Memory DIMMs

7.2.19 Memory Operating Mode

7.2.20 Power Supply Quantity (active / populated / bays)

7.2.21 Power Supply Details

7.2.22 Power Supply Operating Mode

7.2.23 Available Power Supply Modes

7.2.24 Disk Drive Bays (populated / available)

7.2.25 Disk Drive

7.2.26 Network Interface Cards

7.2.27 Management Controller or Service Processor

7.2.28 Expansion Slots (populated / available)

7.2.29 Optical Drives

7.2.30 Keyboard

7.2.31 Mouse

7.2.32 Monitor

7.2.33 Additional Hardware

7.3 Software per Node

7.3.1 Power Management

7.3.2 Operating System (OS)

7.3.3 OS Version

7.3.4 Filesystem

7.3.5 Other Software

7.3.6 Boot Firmware Version

7.3.7 Management Firmware Version

7.3.8 JVM Vendor

7.3.9 JVM Version

7.3.10 Client Configuration ID (formerly SERT Client Configuration)

8. System Under Test Notes

9. Aggregate Electrical and Environmental Data

9.1 Line Standard

9.2 Elevation (m)

9.3 Minimum Temperature (°C)

10. Details Report File

11. Measurement Devices

11.1 Power Analyzer

11.1.1 Hardware Vendor

11.1.2 Model

11.1.3 Serial Number

11.1.4 Connectivity

11.1.5 Input Connection

11.1.6 Metrology Institute

11.1.7 Calibration Laboratory

11.1.8 Calibration Label

11.1.9 Date of Calibration

11.1.10 PTDaemon Version

11.1.11 Setup Description

11.2 Temperature Sensor

11.2.1 Hardware Vendor

11.2.2 Model

11.2.3 Driver Version

11.2.4 Connectivity

11.2.5 PTDaemon Version

11.2.6 Sensor Placement

12. Worklet Performance and Power Details

12.1 Total Clients

12.2 CPU Threads per Client

12.3 Sample Client Command-line

12.4 Performance Data

12.4.1 Phase

12.4.2 Interval

12.4.3 Actual Load

12.4.4 Score

12.4.5 Host CV

12.4.6 Client CV

12.4.7 Elapsed Measurement Time (s)

12.4.8 Transaction

12.4.9 Transaction Count

12.4.10 Transaction Time (S)

12.5 Power Data

12.5.1 Phase

12.5.2 Interval

12.5.3 Analyzer

12.5.4 Average Voltage (V)

12.5.5 Average Current (A)

12.5.6 Current Range Setting

12.5.7 Average Power Factor

12.5.8 Average Active Power (W)

12.5.9 Power Measurement Uncertainty (%)

12.5.10 Minimum Temperature (°C)

1. SPEC SERT

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:

• Test harness - Chauffeur
• Workloads
• Power and Temperature Daemon (PTDaemon)

1.1 Test harness - Chauffeur

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.

1.1.1 SERT Director

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

1.1.2 SERT Host

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.

1.1.3 SERT Client

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 after finishing potentially multiple test phases.

1.1.4 SERT Reporter

The reporter gathers the configuration, environmental, power and performance data after a run is complete from the "results.xml" file and compiles it into HTML and text or CSV format result files. It will be started automatically after finishing all workloads by the director 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".

1.1.5 SERT Graphical User Interface

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.

1.2 Workloads

The SERT workloads will take advantage of different server capabilities by using various load patterns, which are intended to stress all major components of a server uniformly. It is highly unlikely that a single workload can be designed which achieves this goal. Therefore, the SERT workloads will 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:

• CPU
• Memory
• Storage IO
• Hybrid

1.3 The Power and Temperature Daemon

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, the SERT Run and Reporting Rules section 2.9 require it to be run on the controller.

1.4 Result Validation and Report Generation

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 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 this test run. Again basic validity checks are performed, to ensure that interval length, target load throughput, temperature etc. are within the defined limits. For more information see section "6.3 Validation / Verification" in the SERT Design document.

1.5 References

More detailed information can be found in the documents shown in the following table. For the latest versions, please consult SPEC's website.

• config-all.xml
  The main SERT configuration file including the configurable parameters defining the execution of a SERT test run, e.g. the specification of storage test devices, durations of test intervals, enabling or disabling of workloads and/or worklets etc. Before editing this configuration file you should carefully read sections 3. - 5. in the SERT User Guide, see: http://www.spec.org/sert/docs/SERT-User_Guide.pdf.



• config-all-expert.xml
  An alternate version of the main SERT configuration file including extended configuration capabilities which can be used for non compliant modifications by experts.
  Please note that using this version of the main SERT configuration file will typically result in non compliant SERT runs. This file is meant for reasearch usage by experienced SERT users.



• config-rangeSetting.xml
  This file includes definitions for an abbreviated SERT test with selected worklets and load levels only. It is intended to measure the maximum current for worklets and load levels in order to specify the amps range settings for the full SERT test. A description how to use this configuration file is given in the SERT User Guide section "6. Automating Range Setting for Power Analyzers - Optional", see: http://www.spec.org/sert/docs/SERT-User_Guide.pdf.



• config-verifyMultiNode.xml
  This file includes definitions for an abbreviated SERT test with selected worklets and load levels only. It is intended for doing quick performance verification (all nodes produce about the same performance) for a multi-node setup. This will allow users to validate their multi-node setup, before kicking off a full run.



• listeners.xml
  This file includes the interface and parameter definitions for possibly multiple PTDaemon instances and the Graphical User Interface (GUI). Especially the power analyzer range settings for the different worklets and load levels must be specified here.



• test-environment.xml
  This file includes a complete description of the SUT hardware and software. If the SERT is started via the GUI, some of the fields can be filled automatically from information found be the discovery scripts. The other fields must be edited manually by the tester.



• client-configurations-NNN.xml
  This file was introduced with the SERT V1.0.1 release. It specifies predefined sets of JVM options for the different architecture / operating system / JVM combinations to be used for running the tests. Starting with SERT V1.1.0 a version number is appended to the file name.
  The authoritative versions of this file are located on the SPEC web site here:
  For SERT versions V1.0.2 or earlier:
  http://www.spec.org/sert/docs/client-configurations.xml
  For the current SERT version:
  http://www.spec.org/sert/docs/client-configurations-110.xml
  The SERTUI provides support for downloading the current version of this file from the SPEC web site to the local SERT folder.
  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. If the local copy is outdated the latest version has to be downloaded from the SPEC web site location given above.



• obsolete-client-configurations.xml
  This file was introduced in SERT V1.1.0. Configurations in this file are obsolete and should not be used. They are retained here for the purpose of validating old results. Any modifications to this file will be detected and result in being unable to validate results.



• custom-configurations.xml
  Standard client configuration information supplied by SPEC is defined in the file "client-configurations-NNN.xml". This "custom-configurations.xml" file can contain custom configuration data for platforms that are not yet supported by SERT or for research and development purposes. Use of custom configuration data will result in non-compliant SERT runs. Configurations defined in this file will not be selected automatically in the SERT UI, but can be chosen manually by their id. For command-line runs, the client-configuration can be referenced by ID in "config-all.xml".

2. Main Report File

This section gives an overview of the information and result fields in the main report file "results.html/.txt".
Beginning with the SERT V1.0.2 release a new category of SERT results for 32-bit environments was added. The report file headline for 32-bit configurations will show the following addendum:
(32-bit category)
For 64-bit results the headline has no addendum, i.e. it simply reads:
SERT™ Report
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.

3. Top bar

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.

3.1 Test sponsor

The name of the organization or individual that sponsored the test. Generally, this is the name of the license holder <TestSponsor>.

3.2 Software Availability

The date when all the software necessary to run 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 2013-02, but the JVM is not available until 2013-04, then the software availability date is 2013-04 (unless some other component pushes it out farther).

3.3 Tested by

The name of the organization or individual that ran the test and submitted the result <TestedBy>.

3.4 Hardware/Firmware Availability

The date when all the hardware and related firmware modules necessary to run 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 2013-02, but the Firmware version used for the test is not available until 2013-04, then the hardware availability date is 2013-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 http://www.spec.org/osg/policy.html#s2.3.5

3.5 SPEC license #

The SPEC license number of the organization or individual that ran the result <SpecLicense>.

3.6 System Source

Single Supplier or Parts Built <SystemUnderTest><SystemSource>

• Single Supplier
  "Single Supplier" is defined as a SUT configuration where all hardware is provided by a single supplier.
  In case of "Single Supplier" systems all part description fields in the reports, which require detailed information to identify the parts, should include the system vendor name and the system vendor order number for the part.
• Parts Built
  "Parts Built" is defined as a SUT configuration where hardware is provided by multiple suppliers. A "Parts Built" system disclosure must include enough detail to procure and reproduce all aspects of the submission, including performance and power.
  In case of "Parts Built" systems all part description fields in the reports, which require detailed information to identify the parts, must include the part's manufacturer name and the manufacturer's part number to describe the devices.

3.7 Test Location

The name of the city, the state and country the test took place. If there are installations in multiple geographic locations, that must also be listed in this field <Location>.

4 Summary

The summary table presents the efficiency scores for the 4 workloads and the Idle power consumption. These 5 values are intended for use in Energy Efficiency Regulatory Programs of government agencies around the world.
Please note that there is no single overall score, because all workloads are based on synthetic worklets with vastly different load patterns and scores, which cannot be combined in a meaningful way.

4.1 Workload Efficiency Score

The efficiency score for each workload is calculated from the efficiency scores of all its worklets as

"Geometric Mean (Worklet Efficiency Scores)"

4.2 Idle Watts

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 4 workloads.

5 Worklet Summary

This section describes the main results for all worklets in a table and as a graph.

5.1 Result Chart

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

• light blue = CPU workload
• light green = Storage workload
• light purple = Hybrid workload
• light red = Memory workload

• Watts
  The leftmost section displays the range of measured power consumption for all load levels. The Watts values are given on vertical scales at the top of each workload section.
  The power range is represented by a blue line with a dot at the left for minimum power corresponding to the lowest load level and a dot at the right for maximum power corresponding to the highest load level. The intermediate load levels, if defined, are represented by small vertical bars. The vertical blue line accross all worklets within each workload, named "Idle Power" represents the power consumption of the idle worklet. It does not correspond to any load.



• Normalized Performance
  The middle section displays the range of normalized performance values for all load levels. The normalized performance values are given on vertical scales at the top of each workload section. Since SERT release 1.0.1 there are two categories of results:
  • Normalized Performance
    Performance results obtained in 64-bit configurations
  • Normalized Performance (32-bit)
    Performance results obtained in 32-bit configurations
  These values are calculated separately for each load level by taking the interval performance score and dividing it by the corresponding reference score for that worklet. 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 performance range is represented by a red line with a dot at the left for minimum performance corresponding to the lowest load level and a dot at the right for maximum performance corresponding to the highest load level. The intermediate load levels, if defined, are represented by small vertical bars.



• Efficiency Score
  The rightmost section displays the range of efficiency scores for all load levels. The efficiency scores are given on vertical scales at the top of each workload section. Since SERT release 1.0.1 there are two categories of scores:
  • Efficiency Score
    Efficiency scores obtained in 64-bit configurations
  • Efficiency Score (32-bit)
    Efficiency scores obtained in 32-bit configurations
  The efficiency scores are calculated separately for each load level by dividing the normalized-performance for that interval by the average-watts for that interval. Note that the efficiency score for a worklet is NOT the average of the efficiency scores for each interval.
  The efficiency score range is represented by a green line with a triangle at the left for minimum efficiency typically corresponding to the lowest load level and a triangle at the right for maximum efficiency typically corresponding to the highest load level. The intermediate load levels, if defined, are represented by small vertical bars.

5.2 Result Table

The result table numerically displays the power, performance and efficiency scores for the different worklets. Each worklet is presented on a separate row.

5.2.1 Workload

This column of the result table shows the names of the workloads. A workload may include one or more worklets.

5.2.2 Worklet

This column of the result table shows the names of the worklets the following values are belonging to.

5.2.3 Normalized Peak Performance

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. Since SERT release 1.0.1 there are two categories of results:

• Normalized Peak Performance
  Peak performance results obtained in 64-bit configurations
• Normalized Peak Performance (32-bit)
  Peak performance results obtained in 32-bit configurations

5.2.4 Watts at Lowest Load Level

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.

5.2.5 Watts at Highest Load Level

This column of the result table shows the worklet power readings at the highest load level, or "100%" load.

5.2.6 ∑ Normalized Performance

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.
The overall performance score is calculated by summing up the normalized performance scores for all measurement intervals of a worklet. Since SERT release 1.0.1 there are two categories of results:

• ∑ Normalized Performance
  Aggregate performance results obtained in 64-bit configurations
• ∑ Normalized Performance (32-bit)
  Aggregate performance results obtained in 32-bit configurations

5.2.7 ∑ Power (Watts)

The sum of the average-watts for all measurement intervals, see Average Active Power (W) in the "Worklet Performance and Power Details" section.

5.2.8 Efficiency Score

The efficiency score for each worklet is calculated as

1000 * "∑ Normalized Performance" / "∑ Power (Watts)"

• Efficiency Score
  Efficiency scores obtained in 64-bit configurations
• Efficiency Score (32-bit)
  Efficiency scores obtained in 32-bit configurations

6. Aggregate SUT Data

In this section aggregated values for several system configuration parameters are reported.

6.1 # of Nodes

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 the test startup script files.

6.2 # of Processors

The number of processor chips per set and the total number of all chips used for running the test. The reported values are calculated by the test software from the information given in the configuration files and the test startup script files.

6.3 Total Physical Memory

The amount of memory (GB) per set and 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 the test startup script files.

6.4 # of Cores

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 the test startup script files.

6.5 # of Storage Devices

The total number of all storage used for running the test. The reported value is calculated by the test software from the information given in the configuration files and the test startup script files.

6.6 # of Threads

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 the test startup script files.

7. System under test

The following section of the report file describes the hardware and the software of the System Under Test (SUT) used to run the reported SERT results with the level of detail required to reproduce this result.

7.1 Shared Hardware

A table including the description of the shared hardware components. This table will be printed for multi node results only and is missing in single node report files.

7.1.1 Enclosure

The model name identifying the enclosure housing the tested nodes <SystemUnderTest><SharedHardware><Enclosure>.

7.1.2 Form Factor

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

7.1.3 Server Blade Bays (populated / available)

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 <SystemUnderTest><SharedHardware><BladeBays><Populated>.
The second part shows the number of available bays for server blades in the enclosure <SystemUnderTest><SharedHardware><BladeBays><Available>.

7.1.4 Additional Hardware

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.

7.1.5 Management Firmware Version

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

7.1.6 Power Supply Quantity (active / populated / bays)

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

7.1.7 Power Supply Details

The number and watts rating of this power supply unit (PSU) plus the supplier and the part number to identify it.
In 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>.
Potentially there can be multiple lines in this field if different types of PSUs have been used for this test, one for each PSU type.

7.1.8 Power Supply Operating Mode

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

7.1.9 Available Power Supply Modes

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:

• Standard = all populated PSUs are active



• PSU Redundancy = N + M Spare PSU
  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.



• AC Redundancy = N + N (2 AC sources)
  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.

7.1.10 Network Switches (active / populated / bays)

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.

7.1.11 Network Switch

The number and a description of the network switch used for this test, including the manufacturer and the model number to identify it.
<SharedHardware><NetworkSwitches><NetworkSwitch><Active>,
<SharedHardware><NetworkSwitches><NetworkSwitch><Description>, "N/A" if no network switch was used.

7.2 Hardware per Node

This section describes in detail the different hardware components of the system under test which are important to achieve the reported result.

7.2.1 Hardware Vendor

Company which sells the hardware <SystemUnderTest><Node><Hardware><Vendor>

7.2.2 Model

The model name identifying the system under test <SystemUnderTest><Node><Hardware><Model>
Systems which are no longer commercially available must 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 http://www.spec.org/osg/policy.html#s2.3.5

7.2.3 Form Factor

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

7.2.4 CPU Name

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:

• AMD Opteron 6370P
• Fujitsu SPARC64 X+
• IBM POWER8
• Intel Xeon E5-2660 v3
• Oracle SPARC M7

7.2.5 CPU Frequency (MHz)

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:
2900 MHz (up to 3600 MHz), turbo mode enabled

7.2.6 Number of CPU Sockets (available / populated)

This field is divided into 2 parts separated by a slash. The first part gives the number of available CPU sockets and the second part the number of sockets populated with a CPU chip as used for this SERT result.
<SystemUnderTest><Node><Hardware><AvailableSockets>
<SystemUnderTest><Node><Hardware><CPU><PopulatedSockets>

7.2.7 CPU(s) enabled

The CPUs that were enabled and active during the test run, displayed as the number of cores <SystemUnderTest><Node><Hardware><CPU><Cores> the number of processors <SystemUnderTest><Node><Hardware><CPU><PopulatedSockets> and the number of cores per processor <SystemUnderTest><Node><Hardware><CPU><CoresPerChip>.

7.2.8 Number of NUMA Nodes

The number of Non-Uniform Memory Access (NUMA) nodes usesd for this SERT test <SystemUnderTest><Node><Hardware><NumaNodes>.
Typically this is equal to the number of populated sockets times 1 or 2 depending on the CPU architecture.

7.2.9 Hardware Threads / Core

The total number of active hardware threads for this SERT test and the number of harware threads per core given in paranthesis <SystemUnderTest><Node><Hardware><CPU><HardwareThreadsPerCore>.

7.2.10 Primary Cache

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

7.2.11 Secondary Cache

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

7.2.12 Tertiary Cache

Description (size and organization) of the CPU's tertiary, or "L3" cache <SystemUnderTest><Node><Hardware><CPU><Cache><Tertiary>.

7.2.13 Other Cache

Description (size and organization) of any other levels of cache memory <SystemUnderTest><Node><Hardware><CPU><Cache><Other>.

7.2.14 Additional CPU Characteristics

Additional technical characteristics to help identify the processor. <SystemUnderTest><Node><Hardware><CPU><OtherCharacteristics>.

7.2.15 Total Memory Available to OS

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.

7.2.16 Total Memory Amount (populated / maximum)

7.2.17 Total Memory Slots (populated / available)

7.2.18 Memory DIMMs

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>.
Potentially there can be multiple instances of this field if different types of DIMMs have been used for this test, one separate field for each DIMM type.
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:

• "JEDEC Standard No. 21C" http://www.jedec.org/standards-documents/docs/module4_20_26
• DDR4 SDRAM http://www.jedec.org/standards-documents/docs/jesd79-4

• N = number of DIMMs used
  x denotes the multiplication specifier



• gg ss = size of each DIMM, including unit specifier
  256 MB, 512 MB, 1 GB, 2 GB, 4 GB, 8 GB etc.



• pheR = p=number ranks; he=encoding for certain packaging, often blank
  1R = 1 rank of DDR SDRAM installed
  2R = 2 ranks
  4R = 4 ranks



• xff = Device organization (bit width) of DDR SDRAMs used on this assembly
  x4 = x4 organization (4 DQ lines per SDRAM)
  x8 = x8 organization
  x16 = x16 organization



• PCy = Memory module technology standard
  PC4 = DDR4 SDRAM



• v = Module component supply voltage values: e.g. <blank> for 1.2V, L for Low Voltage (currently not defined)



• wwww = module speed in Mb/s/data pin: e.g. 1866, 2133, 2400



• aa = speed grade, e.g.
  J = 10-10-10
  K = 11-11-11
  L = 12-12-12
  M = 13-13-13
  N = 14-14-14
  P = 15-15-15
  R = 16-16-16
  U = 18-18-18



• m = Module Type
  E = Unbuffered DIMM ("UDIMM"), with ECC (x72 bit module data bus)
  L = Load Reduced DIMM ("LRDIMM")
  R = Registered DIMM ("RDIMM")
  S = Small Outline DIMM ("SO-DIMM")
  U = Unbuffered DIMM ("UDIMM"), no ECC (x64 bit module data bus)
  T = Unbuffered 72-bit small outline DIMM ("72b-SO-DIMM")

• 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 DIMM Label", PRN09-NM4, October 2009 http://www.jedec.org/standards-documents/docs/pr-n09-nm1

• N = number of DIMMs used
  x denotes the multiplication specifier



• gg ss = size of each DIMM, including unit specifier
  256 MB, 512 MB, 1 GB, 2 GB, 4 GB, 8 GB etc.



• eR = Number of ranks of memory installed
  1R = 1 rank of DDR SDRAM installed
  2R = 2 ranks
  4R = 4 ranks



• xff = Device organization (bit width) of DDR SDRAMs used on this assembly
  x4 = x4 organization (4 DQ lines per SDRAM)
  x8 = x8 organization
  x16 = x16 organization



• PCy = Memory module technology standard
  PC2 = DDR2 SDRAM
  PC3 = DDR3 SDRAM



• v = Module component supply voltage values: e.g. <blank> for 1.5V, L for 1.35V



• wwwww = Module bandwidth in MB/s
  8500 = 8.53 GB/s (corresponds to 1066 MHz)
  10600 = 10.66 GB/s (corresponds to 1333 MHz)
  12800 = 12.80 GB/s (corresponds to 1600 MHz)
  14900 = 14.90 GB/s (corresponds to 1866 MHz)



• m = Module Type
  E = Unbuffered DIMM ("UDIMM"), with ECC (x72 bit module data bus)
  F = Fully Buffered DIMM ("FB-DIMM")
  M = Micro-DIMM
  N = Mini-Registered DIMM ("Mini-RDIMM"), no address/command parity function
  P = Registered DIMM ("RDIMM"), with address/command parity function
  R = Registered DIMM, no address/command parity function
  S = Small Outline DIMM ("SO-DIMM")
  U = Unbuffered DIMM ("UDIMM"), no ECC (x64 bit module data bus)



• aa = DDR SDRAM CAS Latency in clocks at maximum operating frequency



• ECC = Additional specification for modules which have ECC (Error Correction Code) capabilities



• CLa = CAS latency if the tester has changed the latency to something other than the default



• slots k, ... l = Numbers denoting the mother board memory slots populated with the memory modules described before

7.2.19 Memory Operating Mode

Description of the memory operating mode. Examples of possible values are:
Standard, Mirror, Spare, Independent
<SystemUnderTest><Node><Hardware><Memory><OperatingMode>.

7.2.20 Power Supply Quantity (active / populated / bays)

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. <SystemUnderTest><Node><Hardware><PowerSupplies><PowerSupply><Active>.
The second part gives the number of bays populated with a power supply. <SystemUnderTest><Node><Hardware><PowerSupplies><PowerSupply><Populated>.
The third part describes the number of power supply bays available in this node. <SystemUnderTest><Node><Hardware><PowerSupplies><Bays>.
All three parts can can show "None" if the node is powered by a shared power supply.

7.2.21 Power Supply Details

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>.
Potentially there can 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.

7.2.22 Power Supply Operating Mode

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

7.2.23 Available Power Supply Modes

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:

• Standard = all populated PSUs are active



• PSU Redundancy = N + M Spare PSU
  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.



• AC Redundancy = N + N (2 AC sources)
  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.

7.2.24 Disk Drive Bays (populated / available)

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. <SystemUnderTest><Node><Hardware><DiskDrives><DiskGroup><Quantity>.
The second part shows the number of available drive bays in the SUT, some of them may have been empty in the tested configuration. <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.

7.2.25 Disk Drive

This field contains four rows. In case of heterogenous multi disk configurations there may be several instances of this field.

• Row 1 shows a description of the disk drive(s) (count, supplier name and order number) installed on the SUT
  In case of a "Parts Built" system (see: System Source) the manufacturer name and the part number of the disk drive must be specified here.
  <SystemUnderTest><Node><Hardware><DiskDrives><DiskGroup><Quantity>,
  <SystemUnderTest><Node><Hardware><DiskDrives><DiskGroup><Vendor>,
  <SystemUnderTest><Node><Hardware><DiskDrives><DiskGroup><Model>,
• Row 2 displays the main technical parameters of the disk drive(s) (size, connectivity and rotational speed) installed on the SUT
  <SystemUnderTest><Node><Hardware><DiskDrives><DiskGroup><CapacityGB>,
  <SystemUnderTest><Node><Hardware><DiskDrives><DiskGroup><Connectivity>,
  <SystemUnderTest><Node><Hardware><DiskDrives><DiskGroup><Type>.
• Row 3 describes the manufacturer and model number of the controller used to drive the disk(s)
  <SystemUnderTest><Node><Hardware><DiskDrives><DiskGroup><Controller>.
• Row 4 includes a confirmation that all controller and disk caches have been switched off (write through mode) for running the SERT storage worklets
  <SystemUnderTest><Node><Hardware><DiskDrives><DiskGroup><Settings>. This is a prerequisite to achieve comparable test results.

7.2.26 Network Interface Cards

This field contains three rows. In case of heterogenous configurations with different Network Interface Cards (NICs) there may be several instances of this field.

• Row 1 shows a description of the network controller(s) (number, supplier name, order number and port count) installed on the SUT
  In case of a "Parts Built" system (see: System Source) the manufacturer name and the part number of the network controller must be specified here.
  <SystemUnderTest><Node><Hardware><NetworkInterfaces><NicGroup><Quantity>,
  <SystemUnderTest><Node><Hardware><NetworkInterfaces><NicGroup><Description>.
• Row 2 is divided into 3 comma separated parts.
  Example: 1 connected, 4 enabled in OS, 4 enabled in firmware
  The first part gives the number of physically linked ports
  <SystemUnderTest><Node><Hardware><NetworkInterfaces><NicGroup><Enabled><Connected>.
  The remaining 2 parts give the number of ports enabled in the operating system and in the firmware respectively.
  <SystemUnderTest><Node><Hardware><NetworkInterfaces><NicGroup><Enabled><OS>,
  <SystemUnderTest><Node><Hardware><NetworkInterfaces><NicGroup><Enabled><Firmware>.
• Row 3 describes the configured transfer rate as used for the SERT test run in Mbit/s.
  <SystemUnderTest><Node><Hardware><NetworkInterfaces><NicGroup><SpeedMbps>.

7.2.27 Management Controller or Service Processor

Specifies whether any management controller was configured in the SUT
<SystemUnderTest><Node><Hardware><ManagementController><Quantity>.

7.2.28 Expansion Slots (populated / available)

This field is divided into 2 parts separated by a slash. Potentially there can 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, <SystemUnderTest><Node><Hardware><ExpansionSlots><ExpansionSlot><Populated>.
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><Quantity>.

7.2.29 Optical Drives

Specifies whether any optical drives were configured in the SUT <SystemUnderTest><Node><Hardware><OpticalDrives>.

7.2.30 Keyboard

The type of keyboard (USB, PS2, KVM or None) used <SystemUnderTest><Node><Hardware><Keyboard>.

7.2.31 Mouse

The type of mouse (USB, PS2, KVM or None) used <SystemUnderTest><Node><Hardware><Mouse>.

7.2.32 Monitor

Specifies if a monitor was used for the test and how it was connected (directly or via KVM) <SystemUnderTest><Node><Hardware><Monitor>.

7.2.33 Additional Hardware

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

7.3 Software per Node

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.

7.3.1 Power Management

This field shows whether power management features of the SUT were enabled or disabled
<SystemUnderTest><Node><Software><OperatingSystem><PowerManagement>.

7.3.2 Operating System (OS)

Operating system vendor and name
<SystemUnderTest><Node><Software><OperatingSystem><Vendor>,
<SystemUnderTest><Node><Software><OperatingSystem><Name>.
Examples:

• IBM AIX
• Microsoft Corporation Windows Server 2008 R2 Enterprise SP1
• Oracle Solaris
• Red Hat Enterprise Linux 6.4
• SUSE Linux Enterprise Server 11 SP3

7.3.3 OS Version

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:

• Windows:
  Version 6.1.7601 Service Pack 1 Build 7601
• Linux:
  2.6.32-358.el6.x86_64
• Solaris:
  11.3
• AIX:
  7100-00-10-1334

7.3.4 File System

The type of the filesystem containing the operating system files and directories and test files for the storage worklets. <SystemUnderTest><Node><Software><OperatingSystem><FileSystem>.

7.3.5 Additional Software

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

7.3.6 Boot Firmware Version

A version number or string identifying the boot firmware installed on the SUT. <SystemUnderTest><Node><Firmware><Boot><Version>.

7.3.7 Management Firmware 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>.

7.3.8 JVM Vendor

The company that makes the JVM software, <SystemUnderTest><Node><JVM><Vendor>.

7.3.9 JVM Version

Name and version of the JVM software product, as displayed by the "java -version" or "java -fullversion" commands, <SystemUnderTest><Node><JVM><Version>.
Examples:

• Oracle Hotspot:
  Java SE Runtime Environment (build 1.7.0_71-b14)
• IBM J9:
  JRE 1.7.0 IBM Linux build pxa6470sr7fp1-20140708_01(SR7 FP1)

7.3.10 Client Configuration ID (formerly SERT Client Configuration)

Beginning with SERT V1.0.1 this field shows the label of the client configuration element from the "client-configurations-NNN.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
http://www.spec.org/sert/docs/client-configurations-110.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.

The following description is valid for SERT V1.0.0 result files only:
Labels identifying the option sets being used for the different workloads, e.g. CPU:H4 or Memory:J2.
The labels and their corresponding option-sets are defined in a document on the SPEC web site for each hardware, OS, JVM, workload combination, see: http://www.spec.org/sert/SERT-JVM_Options.html
For valid SERT results the predefined option-sets must be used. The definition file should be checked for updates regularly as new OS or JVM service packs may cause changes in the mandatory set of JVM flags, to be used for the given configuration.
The JVM flags actually used for a SERT test are either determined by the SERTUI in the "JVM Configuration" panel or have to be specified manually in the "config-all.xml" configuration file if the SERT is started from command line, <suite><definitions><option-set><parameter>.
The content displayed here is taken from the <TestEnvironment><configuration><suite><client-configuration id> field of the "results.xml" file generated during the test run.

8. System Under Test Notes

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:

• System tuning parameters other than default.
• Processor tuning parameters other than default.
• Process tuning parameters other than default.
• Changes to the background load, if any, e.g. disabling OS services.
• Critical customer-identifiable firmware or option versions such as network and disk controllers.
• Definitions of tuning parameters must be included.
• Part numbers or sufficient information that would allow the end user to order the SUT configuration.
• Identification of any components used that are supported but that are no longer orderable by ordinary customers.
• OS patches that affect performance and / or power.

9. Aggregate Electrical and Environmental Data

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

9.1 Line Standard

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

9.2 Elevation (m)

Elevation of the location where the test was run. This inforamtion is provided by the tester <SystemUnderTest><TestInformation><ElevationMeters>.

9.3 Minimum Temperature (°C)

Minimum temperature which was measured by the temperature sensor during all target load levels.

10. Details Report File

The details report file "results-details.html/.txt" is created together with the standard report file at the end of each succesfull SERT run. In addition to the information in the standard report file described above it does include more detailed performance and power result values for all Worklets separately.

11. Measurement Devices

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 an extra table.

11.1 Power Analyzer "Name"

The following table includes information about the power analyzer indentified by "Name" and used to measure the electrical data.

11.1.1 Hardware Vendor

Company which manufactures and/or sells the power analyzer <SystemUnderTest><MeasurementDevices><PowerAnalyzer><HardwareVendor>.

11.1.2 Model

The model name of the power analyzer type used for this test run <SystemUnderTest><MeasurementDevices><PowerAnalyzer><Model>.

11.1.3 Serial Number

The serial number uniquely identifying the power analyzer used for this test run <SystemUnderTest><MeasurementDevices><PowerAnalyzer><SerialNumber>.

11.1.4 Connectivity

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 etc. <SystemUnderTest><MeasurementDevices><PowerAnalyzer><Connectivity>.

11.1.5 Input Connection

Input connection used to connect the load, if several options are available, or "Default" if not <SystemUnderTest><MeasurementDevices><PowerAnalyzer><InputConnection>.

11.1.6 Metrology Institute

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:

11.1.7 Calibration Laboratory

Name of the organization that performed the power analyzer calibration according to the standards defined by the national metrology institute. Could be the analyzer manufacturer, a third party company, or an organization within your own company <SystemUnderTest><MeasurementDevices><PowerAnalyzer><AccreditedBy>.

11.1.8 Calibration Label

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

11.1.9 Date of Calibration

The date (yyyy-mm-dd) the calibration certificate was issued, from the calibration label or the calibration certificate <SystemUnderTest><MeasurementDevices><PowerAnalyzer><DateOfCalibration>.

11.1.10 PTDaemon Version

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.

11.1.11 Setup Description

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

11.2 Temperature Sensor

The following table includes information about the temperature sensor used to measure the ambient temperature of the test environment.

11.2.1 Hardware Vendor

Company which manufactures and/or sells the temperature sensor <SystemUnderTest><MeasurementDevices><TemperatureSensor><HardwareVendor>.

11.2.2 Model

The manufacturer and model name of the temperature sensor used for this test run <SystemUnderTest><MeasurementDevices><TemperatureSensor><Model>.

11.2.3 Driver Version

The version number of the operating system driver used to control and read the temperature sensor. <SystemUnderTest><MeasurementDevices><TemperatureSensor><DriverVersion>.

11.2.4 Connectivity

Which interface was used to read the temperature data from the sensor, e.g. RS-232 (serial port), USB etc. <SystemUnderTest><MeasurementDevices><TemperatureSensor><Connectivity>.

11.2.5 PTDaemon Version

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.

11.2.6 Sensor Placement

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

12. Worklet Performance and Power Details

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 segmant includes Performance and Power Data tables together with some details about the client JVMs for the corresponding Worklet.

12.1 Total Clients

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-NNN.xml" file.
See Client Configuration ID for more details.

The following description is valid for SERT V1.0.0 and V1.0.1 result files only:
Although this number needs to be specified manually in the "config-all.xml" configuration file <launch-definition><num-clients>, it must match the JVM client count defined in the option-set definition file for this hardware, OS, JVM, workload combination. If not, the result will be marked invalid.
The option-set definition file is available for reference at http://www.spec.org/sert/SERT-JVM_Options.html.
It should be checked for updates regularly as new OS or JVM service packs may cause changes of the number of client JVMs, to be used for the given configuration.

12.2 CPU Threads per Client

The number of hardware threads each instance of the client JVM is affinitized to.

12.3 Sample Client Command-line

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-NNN.xml" file.
See Client Configuration ID for more details.

The following description is valid for SERT V1.0.0 and V1.0.1 result files only:
The JVM tuning flags need to be specified manually in the "config-all.xml" configuration file, <suite><definitions><option-set><parameter>.
They must match the JVM flags defined in the option-set definition file for this hardware, OS, JVM, workload combination. If not, the result will be marked invalid.
The option-set definition file is available for reference at http://www.spec.org/sert/SERT-JVM_Options.html.
It should be checked for updates regularly as new OS or JVM service packs may cause changes in the mandatory set of JVM flags, to be used for the given configuration.

12.4 Performance Data

This table displays detailed performance information for a worklet. The information is presented on separate rows per Phase, Interval and Transaction where applicable.

12.4.1 Phase

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 "warm-up", "Calibration" and "Measurement"

12.4.2 Interval

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%"

12.4.3 Actual Load

The "Actual Load" is calculated 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.

12.4.4 Score

The fields in this column show the worklet specific score for each interval, which is calculated dividing the sum of all "Transaction Count" values for this interval by the "Elapsed Measurement Time (s)".
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 (Flood and Capacity) have their own score calculations that include other factors, e.g. memory capacity. A detailed description is given in the SERT Design Document http://www.spec.org/sert/docs/SERT-Design_Doc.pdf.

Beginning with SERT release 1.1.0 the algorithm to calculate memory worklet scores has changed. Therefore memory worklet scores from pre SERT 1.1.0 releases are no longer directly comparable to those from SERT 1.1.0 and newer releases. Pre SERT 1.1.0 results can be recalculated to match new results using the following formulas:

• 64-bit:
  
  • Flood2 (SERT 1.1.0) efficiency score= Flood (SERT 1.0.x) efficiency score * 2.828125 / sqrt(PhysicalMemoryGB)
  • Capacity2 (SERT 1.1.0) efficiency score = Capacity (SERT 1.0.x) * 0.883530 * sqrt(PhysicalMemoryGB) / ((PhysicalMemoryGB - 1) * 0.357 )


• 32-bit (with ≤ 8GB Physical Memory):
  
  • Flood2 (SERT 1.1.0) efficiency score=Flood (SERT 1.0.x) efficiency score * 1.788404 / sqrt(PhysicalMemoryGB))
  • Capacity2 (SERT 1.1.0) efficiency score=Capacity efficiency score * 0.558653 * sqrt(PhysicalMemoryGB) / (PhysicalMemoryGB * 0.312375)


• 32-bit (with > 8GB Physical Memory):
  
  • Flood2 (SERT 1.1.0) efficiency score=Flood (SERT 1.0.x) efficiency score * 1.788404 / sqrt(PhysicalMemoryGB))
  • Capacity2 (SERT 1.1.0) efficiency score=Capacity efficiency score * 0.558653 * sqrt(PhysicalMemoryGB) / ((PhysicalMemoryGB - 1) * 0.357)

12.4.5 Host CV

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

c_v = σ ⁄ μ

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.

12.4.6 Client CV

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

c_v = σ ⁄ μ

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.

12.4.7 Elapsed Measurement Time (s)

The time spent during this interval executing transactions. This is the time used for calculating the "Score" for this interval.
This time typically doesn't match exactly the interval time specified in the SERT configuration file "config-all.xml".

12.4.8 Transaction

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. Hybrid: SSJ, run several different transactions. There will be a separate line for each transaction.

12.4.9 Transaction Count

The number of successfully completed transactions defined in column "Transaction" during the interval given in column "Interval".
For worklets including multiple transactions a "sum" field is added, showing the aggregated transaction count for all transactions of this worklet.

12.4.10 Transaction Time (s)

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 transactions a "sum" field is added, showing the aggregated transaction time for all transactions of this worklet.

12.5 Power Data

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.

12.5.1 Phase

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

12.5.2 Interval

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

12.5.3 Analyzer

Name indentifying 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.

12.5.4 Average Voltage (V)

Average voltage in V for each interval as reported by the PTDaemon instance connected to this power analyzer.

12.5.5 Average Current (A)

Average current in A for each interval as reported by the PTDaemon instance connected to this power analyzer.

12.5.6 Current Range Setting

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.

12.5.7 Average Power Factor

Average power factor for each interval as reported by the PTDaemon instance connected to this power analyzer.

12.5.8 Average Active Power (W)

Average active power in Watt 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.

12.5.9 Power Measurement Uncertainty (%)

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 "1.20.1 Power Analyzer Requirements" of the SERT-Run_and_Reporting_Rules.pdf 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.

12.5.10 Minimum Temperature (°C)

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 - 2016 Standard Performance Evaluation Corporation
All Rights Reserved

---

Home - Contact - Site Map - Privacy - About SPEC

---

webmaster@spec.org
Last updated: Wed Mar 01 17:50:57 EST 2017
Copyright 1995 - 2024 Standard Performance Evaluation Corporation
URL: http://www.spec.org/sert1/docs/SERT-Result_File_Fields.html