ABSTRACT
This document describes the various fields in the different levels of
result files making up the complete SPECpower_ssj2008 result
disclosure.
Main Report File (ssj.NNNN-main.html)
including the overall metric, the system under test description, the
controller system description, the measurement devices description and
the aggregated measured values (throughput, power and temperature).
Power/Temperature Details Report (ssj.NNNN-power.html){>V1.01 only}
including details for possibly multiple power analyzers and temperature
sensors.
Aggregate Performance Report (ssj.NNNN.details.html)
including more detailed throughput information divided into separate
sections per JVM, per node or per set.
A set consists of one or more identically configured nodes. Currently
only homogeneous configurations with one set are valid for a compliant
benchmark run although multiple heterogeneous sets are supported by the
software.
The aggregate performance report is not generated for single node or
single JVM configurations.
Set 'Set#' Performance Report (ssj.NNNN.details.Set#.html){>V1.01 only}
including more detailed throughput information split into separate
sections per host.
For benchmark versions >V1.01 a set performance report is generated
for heterogeneous configurations including multiple sets only. Such
configurations are not valid for publication but are supported by the
benchmark software.
Host 'Host#' Performance Report (ssj.NNNN.details.Set#.Host#.html){>V1.01 only}
including more detailed throughput information split into separate
sections per JVM instance.
JVM Instance 'Host#.NNN' Performance Report (ssj.NNNN.details.Set#.Host#-Host#.NNN.html)
including the throughput data for each JVM instance separately.
SPECpower_ssj2008 is the first generation SPEC benchmark for
evaluating the power and performance of server class computers.
The benchmark suite consists of three separate software modules:
Workload (SSJ)
Power and Temperature Daemon (PTDaemon)
Control and Collect System (CCS)
These modules work together in real-time to collect server power
consumption and performance data by exercising the system under test
(SUT) with a predefined workload.
The workload is a Java program designed to exercise the CPU(s),
caches, memory, the scalability of shared memory processors, JVM (Java
Virtual Machine) implementations, JIT (Just In Time) compilers, garbage
collection, threads, and certain aspects of the operating system of the
SUT.
The workload architecture is a 3-tier system with emphasis on the
middle tier. These tiers are comprised as follows:
Random input selection
Business logic (fully implemented by SPECpower_ssj2008)
Tables of objects, implemented by Java Collections (rather than a
separate database)
The JVM Director is a separate and distinct mechanism from the
actual workload itself (the three-tiered client-server environment),
but runs concurrently with the JVM instance(s) of the workload. Like
the workload, the JVM Director is also a java application, and as such,
runs as its own JVM instance.
The JVM Director can be run locally on the SUT, or it can be run
remotely at the user�s discretion (see Director
Location). Whichever method is employed, the JVM Director and the
workload JVM instance(s) will communicate via a TCP/IP socket
connection.
The Control and Collect System is a Java-based application that resides
on the controller server. CCS is used to connect to three types of data
sources via TCP/IP socket communication:
the SSJ module (via the JVM Director) on the SUT
one ore more instances of PTDaemon each connected to a power
analyzer
one or more instances of PTDaemon each connected to a temperature
sensor
One of CCS�s main functions is to initiate the SPECpower_ssj2008
benchmark iteration. After the benchmark run has started, CCS then
collects and synchronizes power data, temperature data, and workload
data from the three data sources in real time. CCS then outputs this
data into the result files described in this 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 CCS 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 of the three SPECpower_ssj2008 software
modules that is not Java based. Although it can be quite easily setup
and run on a server other than the controller server, in the simplest
SPECpower_ssj2008 test bed implementation, the PTDaemon will typically
reside on the controller server.
At the beginning of each run, the benchmark parameters are checked
for conformance to the run rules. Warnings are displayed for
non-compliant properties and printed in the final report; however, the
benchmark will run to completion producing a report that is not valid
for publication.
At the end of a benchmark 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 benchmark run. Again
basic validity checks are performed, to ensure that interval length,
target load throughput, temperature etc. are within the limits defined
in the run rules. For more information see section "2.5.2 Validity
Checks" in the
Run and Reporting Rules document.
In this document all references to configurable parameters are printed
in parentheses with red color using the names from the properties
files, e.g. (config.test.sponsor)
from "SPECpower_ssj_config.props".
The following properties files are delivered with the benchmark kit:
ccs.props
The CCS properties file includes descriptions of the controller system (ccs.config......) and basic information on
the power analyzers and temperature sensors (ptd.pwr1.config......).
Also the workload to be run is selected and additional parameters are
defined. (ccs.wkld......).
Currently only one workload (SSJ) is supported.
SPECpower_ssj.props
This file includes the global control parameters for the SSJ workload
which can be changed by the user without invalidating the benchmark
results (input.calibration.interval_count).
SPECpower_ssj_EXPERT.props
This file is a superset of the default "SPECpower_ssj.props"
configuration file and will be needed for experimental use of the
benchmark only. Besides the control parameters allowed to be changed (input.calibration.interval_count) it also
includes options for the fixed input parameters which cause an invalid
result if changed (input.load_level.count).
SPECpower_ssj_config.props
The characteristics of the test run (config.test......)
are specified in this file together with a description of the shared
hardware in case of a multi node run (config.shared......).
SPECpower_ssj_config_<set_id>.props {>V1.01
only}
Detailed hardware (config.hw.....)
and software (config.sw.....)
descriptions of the system under test are stated here. Each instance of
this file describes a single host system or several identically
configured systems in a set. A heterogeneous configuration with
differently configured systems requires one properties file per set.
This file resides on the system running the JVM Director.
Currently only single set homogeneous configurations are allowed for a
valid benchmark run.
This section gives an overview of the information and result fields
in the main report file. Additional information is shown in the Power/Temperature Details Report, including
detailed power information for potentially multiple power analyzers,
and the Aggregate Performance Report,
which is generated for multiple node tests only. The Set Performance Report represents the next
level of details and is created only if multiple heterogeneous sets of
nodes are used, which is currently not allowed for valid results.
This information is further extended in the Host
Performance Report and the JVM Instance
Performance Report which are generated for each host and each JVM
instance including specific configuration and performance details.
The headline of the performance report includes one field displaying
the hardware vendor (config.hw.vendor)
and the name (config.hw.model) of the
system under test. In a second field the overall SPECpower_ssj2008
result achieved in this test (overall ssj_ops/watt) is printed,
eventually prefixed by an "Invalid" indicator, if the current result
does not pass the validity checks implemented in the SPECpower_ssj
report generation software. More detailed information about the result
metric is presented in section 3.1 of the SPECpower_ssj2008
Run and Reporting Rules.
The date when all the hardware necessary to run
the
result is generally available (config.hw.available).
For example, if the CPU is available in Aug-2007, but the memory is not
available until Oct-2007, then the hardware availability date is
Oct-2007 (unless some other component pushes it out farther).
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 (config.test.location).
The date when all the software necessary to run
the
result is generally available (config.sw.available).
For example, if the operating system is available in Aug-2007, but the
JVM is not available until Oct-2007, then the software availability
date is Oct-2007 (unless some other component pushes it out farther).
Single Supplier or Parts Built (config.hw.system_source)
Single Supplier
"Single Supplier" is defined as a SUT configuration where all hardware
is provided by a single supplier.
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.
The date when the test is run. This value is automatically supplied
by the SPECpower_ssj software; the time reported by the system under
test is recorded in the raw result file .
The date when this report will be published after finishing the
review. This date is automatically filled in with the correct value by
the submission tool provided by SPEC.
By default this field is set to "Unpublished" by the software
generating the report.
Possible values for this property (config.test.method)
are:
Single Node
"Single Node" is defined as a SUT configuration where the test is
performed on one server running a single OS image (see section 2.11 of
the
SPECpower_ssj2008 Run and Reporting Rules).
Homogeneous Multi Node
"Homogeneous Multi Node" is defined as a SUT configuration where the
test is running on multiple, identically configured ("homogeneous")
servers sharing some energy efficiency feature (see section 2.11 of the
SPECpower_ssj2008 Run and Reporting Rules).
Heterogeneous Multi Node (Not Valid for
Publication)
"Heterogeneous Multi Node" this SUT configuration is composed of
multiple, differently configured ("heterogeneous") servers sharing some
energy efficiency feature (see section 2.11 of the
SPECpower_ssj2008 Run and Reporting Rules).
Possible values for this property (config.hw.system_designation)
are:
Server
"Server" is defined as a computer system that is marketed to support
multiple tasks from multiple users, simultaneously. (see section 3.3.2
of the
SPECpower_ssj2008 Run and Reporting Rules).
Personal System
"Personal System" is a computer system that is primarily marketed for
use by a single individual, even though multiple tasks may execute
simultaneously (see section 3.3.2 of the
SPECpower_ssj2008 Run and Reporting Rules).
Battery-powered
A computer system designed to be able to run normal operations without
an external source of power (see section 2.8 of the
SPECpower_ssj2008 Run and Reporting Rules).
Any inconsistencies with the run and reporting rules causing a
failure of one of the validity checks implemented in the report
generation software will be reported here and all pages of the report
file will be stamped with an "Invalid" water mark in case this happens.
The printed text will show more details about which of the run rules
wasn't met and the reason why.
(see section 2.5.2 of the
SPECpower_ssj2008 Run and Reporting Rules).
The first three columns of the results table show the measured
throughput and the actual percentage of calibrated throughput compared
to the target percentage.
The different target load levels derived from the calibrated
throughput, starting with 100% of the calibrated throughput and
decreasing to "Active Idle" = 0% or no throughput. The benchmark
software schedules the required number of requests to actually achieve
the intended throughput levels during each of the measurement
intervals, each lasting 240 seconds.
The load levels actually achieved during the different phases of the
benchmark as a percentage of the calibrated throughput. The percentages
must match the target load of each phase with less than 2% deviation
(positive or negative).
The number of operations finished during this measurement interval
divided by the number of seconds defined for this interval, showing the
throughput (workload operations per second) for this period.
The last measurement interval running without any transactions
scheduled by the workload software. So there is no throughput reported
for this interval only the power consumption will be measured and
displayed.
Average active power measured by the power analyzer(s) and
accumulated by the PTDaemon (Power and Temperature Daemon) for this
measurement interval, displayed as watts (W).
The result chart graphically displays the results reported in the
summary table in one diagram.
The red bars show the performance to power ratio (throughput / W) of
each target load given on the y-axis graphically (corresponding to the
upper x-axis) and numerically as a label in the bar. Longer bars /
higher numbers are better.
By definition there is no throughput for the "Active Idle" level and so
the ratio is always 0.
The bold blue line with the markers corresponds to the lower x-axis and
shows the average power consumption for each target load given on the
y-axis. Lower numbers are better.
The thin, vertical, straight line corresponds to the upper x-axis and
shows the overall ssj_ops per watt result of the benchmark. A higher
number is better.
In this section aggregated values for several system configuration
parameters are reported. The section will be displayed only if more
than one node is configured.
A user defined identifier (see (SETID)
in runssj.bat/runssj.sh) used to identify the descriptive configuration
properties that will be used for the system under test. For example,
with a (SETID) of "sut", the
descriptive configuration properties will be read from the file
"SPECpower_ssj_config_sut.props" from the Director system.
The number of nodes per set and the total number of all nodes used
for running the test.
The reported values are calculated by the benchmark software from the
information given in the properties files and the benchmark startup
script files.
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 benchmark software from the
information given in the properties files and the benchmark startup
script files.
The number of processor cores per set and the total number of all
cores used for running the test.
The reported values are calculated by the benchmark software from the
information given in the properties files and the benchmark startup
script files.
The number of processor threads per set and the total number of all
threads used for running the test.
The reported values are calculated by the benchmark software from the
information given in the properties files and the benchmark startup
script files.
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 benchmark software from the
information given in the properties files and the benchmark startup
script files.
The number of operating system images per set and the total number
of all OS images used for running the test.
The reported values are calculated by the benchmark software from the
information given in the properties files and the benchmark startup
script files.
The number of Java Virtual Machine instances per set and the total
number of all JVM instances used for running the test.
The reported values are calculated by the benchmark software from the
information given in the properties files and the benchmark startup
script files.
The following section of the report file describes the hardware and
the software of the system under test (SUT) used to run the reported
SPECpower benchmark with the level of detail required to reproduce this
result.
The full SUT form factor (including all nodes and any shared
hardware). (config.shared.form_factor).
For rack-mounted systems, specify the number of rack units. For other
types of enclosures, specify "Tower" or "Other".
The number of power supplies that are installed in the tested
configuration (config.shared.psu.installed)
and the power rating for each power supply (config.shared.psu.rating).
Both values are set to 0 if there are no shared power supplies.
The manufacturer of the network switch and the model number to
identify it
(config.shared.network.switch.description).
"N/A" if there is no network switch.
A unique identifier for this set of nodes.
This number or string is read by the benchmark program from the
"-setid" commandline parameter used to start the SSJ code of the
benchmark and reported here.
(see (SETID) in runssj.bat/runssj.sh)
The number of identically configured nodes which constitute this
set. This number is read by the benchmark program from the "-numHosts"
commandline parameter used to start the director code of the benchmark
and reported here.
(see (NUM_HOSTS) in
rundirector.bat/rundirector.sh)
The form factor for this system (config.hw.form_factor).
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".
Technical characteristics to help identify the processor, such as
number of cores, frequency, cache size etc (config.hw.cpu.characteristics).
If the CPU is capable of automatically running the processor core(s)
faster than the nominal frequency and this feature is enabled, this
field should also list the feature and the maximum frequency it enables
on that CPU (e.g.: "Intel Turbo Boost Technology up to 3.46GHz").
If this CPU clock feature is present but is disabled, no additional
information is required here.
The nominal (marked) clock frequency of the CPU, expressed in
megahertz.
(config.hw.cpu.mhz).
If the CPU is capable of automatically running the processor core(s)
faster than the nominal frequency and this feature is enabled, then the
CPU Characteristics field must list
additional information, at least the maximum frequency and the use of
this feature.
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.
The CPUs that were enabled and active during the benchmark run,
displayed as the number of cores (config.config.hw.cpu.cores),
the number of chips (config.config.hw.cpu.chips)
and the number of cores per chip (config.config.hw.cpu.cores_per_chip).
Detailed description of the system main memory technology,
sufficient for identifying the memory used in this test.
(config.hw.memory.description).
The recommended format is described here.
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)
ECC = Additional specification for modules which have ECC
(Error Correction Code) capabilities
CLa = DDR SDRAM CAS Latency in clocks at maximum operating
frequency
slots k, � l = Numbers denoting the mother board memory
slots populated with the memory modules described before
The number of power supplies that are installed in the tested
configuration (config.hw.psu.installed)
and the power rating for each power supply (config.hw.psu.rating).
This field can show "None" if the node is powered by a shared power
supply.
The manufacturer of the power supply and the model number to
identify it. (config.hw.psu.description).
"N/A" if this node does not include a power supply.
A description of the disk drive(s) (count, model, size, type,
rotational speed and RAID level if any) used to boot the operating
system and to hold the benchmark software and data during the run (config.hw.disk).
The number of NICs (ports) enabled in the Firmware, in the OS and
actually connected during the test (config.hw.network.controller.enabled.firmware,
config.hw.network.controller.enabled.os,
config.hw.network.controller.connected).
The network speed actually used on the configured NICs during the
test (config.hw.network.speed).
A minimal speed of at least 1 Gbit/sec is required for a valid
benchmark run.
This section describes in detail the various software components
installed on the system under test, which are important to achieve the
reported result, and their configuration parameters.
The operating system version. If there are patches applied that
affect performance, they must be disclosed in the
System Under Test Notes(config.sw.os.version).
How many megabytes initially used by the JVM heap. "Unlimited" or
"dynamic" are allowable values for JVMs that adjust automatically (config.sw.jvm.heap.initial).
How many megabytes can maximally be used by the JVM heap.
"Unlimited" or "dynamic" are allowable values for JVMs that adjust
automatically (config.sw.jvm.heap.max).
A version number or string identifying the management firmware
running on the SUT or "None" if no management controller was installed.
(config.sw.mgmt_firmware.version).
The name and revision number of the workload program used to produce
this result. This information is provided automatically by the
benchmark software.
Indentifies the system which hosts the director controlling the
different JVM instances (SUT, Controller or other). Locations other
than SUT or Controller require additional description under Notes(config.director.location).
Any performance-relevant software used and required to reproduce the
reported scores, including third-party libraries, accelerators, etc. (config.sw.other)
Free text description of what sort of tuning one has to do to the
boot firmware to get these results, e.g configuration settings changed
from the default.
(config.sw.boot_firmware.settings).
Free text description of what sort of tuning one has to do to the
management firmware to get these results or "None" if no management
controller was installed, e.g configuration settings changed from the
default.
(config.sw.mgmt_firmware.settings).
Free text description of what sort of tuning one has to do to either
the OS or the JVM to get these results. Also additional hardware
information not covered in the other fields above can be given here.
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.
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.
The required information can be given directly in this section of the
report or a pointer to a separate document hosted by SPEC can be added
here (config.sut.notes).
The name of the processor installed in the controller system (ccs.config.hw.cpu) and some technical
characteristics to help identify the processor, such as number of
cores, frequency, cache size etc (ccs.config.hw.cpu.characteristics)
This section of the report shows the details of the different
measurement devices used for this benchmark run.
Starting with version 1.10 of the benchmark there may be more than one
measurement device used to measure power and temperature.
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. (ptd.pwrN.config.analyzer.connectivity)
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 (ptd.pwrN.config.calibration.accredited_by).
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 calibration institute (ptd.pwrN.config.calibration.label).
The date (DD-MMM-YYYY) the calibration certificate was issued, from
the calibration label or the calibration certificate (ptd.pwrN.config.calibration.date).
The manufacturer and model number of the system connected to power
analyzer and running the power daemon. If PTDaemon is running on the
controller system a reference to this system can be reported instead,
e.g. "Controller". (ptd.pwrN.config.ptd.system)
The name and the version of the operating system installed on the
power daemon host system. If PTDaemon is running on the controller
system a reference to this system can be reported instead, e.g. "same
as Controller". (ptd.pwrN.config.ptd.os)
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
benchmark 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".
(ptd.pwrN.config.analyzer.setup_description).
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".
(ptd.tempN.config.sensor.setup_description)
Additional important information required to reproduce the results
from other reporting sections, i.e. not related to the SUT, that
require a larger text area.
(config.notes).
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 benchmark result. For further
explanation of the measured values look in the "SPECpower Methodology"
document (SPECpower-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 (config.line.standard.voltage,
config.line.standard.frequency, config.line.standard.phase,
config.line.standard.wires).
The minimum ambient temperature for each of the target load levels
measured by the temperature sensor.
All values are measured in ten second intervals, evaluated by the
PTDaemon and reported to the collection system at the end of each
target load level.
This section describes the aggregated throughput for all JVM
instances measured during all test phases including the calibration
intervals in a table and as a graph.
Load levels as described in paragraph Target
Load plus the calibration phases at the beginning. The number of
calibration phases can be configured by the tester (config.input.calibration.interval_count),
minimum = 3, maximum = 10.
The calibrated throughput is calculated from the average throughput
of the last two calibration phases. It is required to run at least
three calibration phases and at most ten (config.input.calibration.interval_count).
The result chart graphically displays the throughput results
reported in the aggregate performance data table in one diagram. The
blue line with the square data points represents the target values and
the red line with the rotund data points represents the actually
measured throughput values for the different test phases as indicated
on the x-axis. The throughput values are shown on the y-axis, higher
values are better. The thin horizontal line at the top shows the
maximal throughput calculated from the calibration runs.
This section shows the measured SPECpower_ssj2008 result and gives
some general information regarding this test run.
For more details see section Top bar.
This section presents the aggregated active power consumption (see Average Active Power (W)) and the minimum
temperature (see Minimum Ambient Temperature (°C)) for all test phases (see Target
Load).
The chart to the right graphically displays the power and temperature
values from the summary table. The red line with the square data points
represents the power consumption in W and the blue line with the rotund
data points represents the minimum temperature values in °C for the
different test phases as indicated on the x-axis. The power values are
shown on the left y-axis, lower numbers are better. The temperature
values are shown on the right y-axis.
The thin red horizontal line indicates the average power consumption
for the target loads not including the calibration phases.
The voltage range for each test phase as configured in the power
analyzer. Typically range settings are read by PTDaemon directly from
the power analyzer. If a power analyzer does not support range reading
the values are taken from the (ptd.pwr1.config.analyzer.voltage_range)
property in the "ccs.props" file.
Please note that automatic voltage range setting by the analyzer is not
allowed for all currently accepted analyzers and will invalidate the
result.
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. If a power analyzer does not support range reading
the values are taken from the (ptd.pwr1.config.analyzer.current_range)
property in the "ccs.props" file.
Please note that automatic current range setting by the analyzer is not
allowed for all currently accepted analyzers and will invalidate the
result.
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.13.2 Power Analyzer
Specifications" of the SPECpower_ssj2008
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 PTDaemon design document, see
SPECpower_ssj2008-Design_ptd.pdf.
This is the third part of the SPECpower_ssj2008 full disclosure
report revising the configuration information and aggregate performance
numbers from the first part plus adding more detailed performance
information if more than one JVM instance was started.
This report is not created for benchmark runs using only one JVM
instance.
This section shows the measured SPECpower_ssj2008 throughput results
and gives some general information regarding this test run.
For more details see section Top bar of the
main report file.
In contrast to the top bar in the main report file the headline does
not show the overall metric but the aggregated performance at 100%
target load for the whole SUT and the average throughput at 100% target
load per Host and per JVM.
This section describes the aggregated throughput for all JVM
instances measured during all test phases including the calibration
intervals in a table and as a graph.
For more details see section Aggregate
Performance Data.
This column of the table names the different sets, the aggregated
throughput for all sets at 100% target load and the average throughput
per Host and per JVM at 100% target load.
The result chart graphically displays the throughput results
reported in the set instance summary table in one diagram. The colored
lines represent the actually measured throughput values of each set for
the different test phases as indicated on the x-axis. The throughput
values are shown on the y-axis, higher values are better. The thin
horizontal line shows the average throughput per set.
This section describes the aggregated throughput for all JVM
instances belonging to this set measured during all test phases
including the calibration intervals in a table and as a graph. The
layout and the information are similar to the "Aggregate Performance
Data" section of the main report file.
For more details see section Aggregate
Performance Data.
This report represents the next level of the SPECpower_ssj2008 full
disclosure report. It describes the configuration and performance
details for a specific set of nodes.
There may exist several of these reports, one for each set.
This report is not created for benchmark runs using only one
homogeneous set of nodes.
This section shows the measured SPECpower_ssj2008 throughput results
for this set of nodes and gives some general information regarding this
test run.
For more details see section Top bar of the
main report file.
In contrast to the top bar in the main report file the headline does
not show the overall metric but the aggregated performance at 100%
target load for the whole set and the average throughput at 100% target
load per Host and per JVM.
This section describes the aggregated throughput for all JVM
instances of this set measured during all test phases including the
calibration intervals in a table and as a graph.
For more details see section Aggregate
Performance Data.
This section repeats set specific information from the corresponding
section of the main report file.
For more details see section System Under
Test Notes.
This section gives an overview of the accumulated throughput for the
different hosts belonging to this set.
For more details regarding the layout and the field names see section Set Instance Summary.
This column of the table names the different hosts, the aggregated
throughput for all hosts at 100% target load and the average throughput
per Host and per JVM at 100% target load.
The result chart graphically displays the throughput results
reported in the host instance summary table in one diagram. The colored
lines represent the actually measured throughput values of each host
for the different test phases as indicated on the x-axis. The
throughput values are shown on the y-axis, higher values are better.
The thin horizontal line shows the average throughput per host.
This section describes the aggregated throughput for all JVM
instances running on host 'N' measured during all test phases including
the calibration intervals in a table and as a graph. The layout and the
information are similar to the "Aggregate Performance Data" section of
the main report file.
For more details see section Aggregate
Performance Data.
This report represents the next level of the SPECpower_ssj2008 full
disclosure report. It describes the configuration and performance
details for a specific node or host.
There may exist several of these reports, one for each host.
This section shows the measured SPECpower_ssj2008 throughput results
for this node and gives some general information regarding this test
run.
For more details see section Top bar of the
main report file.
In contrast to the top bar in the main report file the headline does
not show the overall metric but the aggregated performance at 100%
target load for this node and the average throughput at 100% target
load per JVM.
This section describes the aggregated throughput for all JVM
instances of this host measured during all test phases including the
calibration intervals in a table and as a graph.
For more details see section Aggregate
Performance Data.
This section repeats host specific information from the
corresponding section of the main report file.
For more details see section System Under
Test Notes.
This section gives an overview of the accumulated throughput for the
different JVMs running on this host.
For more details regarding the layout and the field names see section Set Instance Summary.
This column of the table names the different JVM instances, the
aggregated throughput for all JVM instances at 100% target load and the
average throughput per JVM at 100% target load.
The result chart graphically displays the throughput results
reported in the host instance summary table in one diagram. The colored
lines represent the actually measured throughput values of each JVM
instance for the different test phases as indicated on the x-axis. The
throughput values are shown on the y-axis, higher values are better.
The thin horizontal line shows the average throughput per JVM.
This section describes the throughput of one JVM instance measured
during all test phases including the calibration intervals in a table
and as a graph. The layout and the information are similar to the
"Aggregate Performance Data" section of the main report file.
For more details see section Aggregate
Performance Data.
This is the lowest level part of the SPECpower_ssj2008 full
disclosure report revising the configuration information and
performance numbers from the previous level plus adding more detailed
throughput information for different transaction types. There may exist
several of these reports, one for each JVM instance.
This section shows the measured SPECpower_ssj2008 throughput results
for this JVM instance and gives some general information regarding this
test run.
For more details see section Top bar of the
main report file.
In contrast to the top bar in the main report file the headline does
not show the overall metric but the performance at 100% target load for
this JVM.
This section describes the aggregated throughput for this specific
JVM instance measured during all test phases including the calibration
intervals in a table and as a graph.
For more details see section Aggregate
Performance Data.
This section repeats host specific information from the
corresponding section of the main report file.
For more details see section System Under
Test Notes.
