#
# SPECjAppServer2002 submission file
#

# The licensee that is submitting this result to SPEC.
#
submitter.name=IBM Corporation

# The SPEC license number (or membership number) of the company that
# is submitting this result for review.
#
submitter.spec_license=11

# The name and location of the person who created this result.
# NOTE: this name and location does not go into the results page.
#
submitter.internal_name=Christopher James Blythe
submitter.location=Bldg. 503, Research Triangle Park, NC USA

# The title for the result as you wish it to appear on the results 
# page. This title will also appear in the title of the HTML page.
#
system.title=WebSphere 5.0.1 Application Server on eServer xSeries 360 Cluster 

# The SUT category for this result.  Valid categories are:
#   SingleNode 
#   DualNode 
#   MultipleNode 
#   Distributed 
#
system.category=MultipleNode

# The name of the files that contain the configuration diagram and
# the submission archive of the results. When submitting results to
# SPEC, the configuration diagram and archive files should be 
# included along with this file as attachments in the same email
# message.
#
system.diagram.name=x360_cluster.jpg
system.archive.name=x360_cluster.zip

# The total cost for the SUT as defined in section 3 of the Run Rules
#
system.total_cost=290164
system.total_cost_currency_symbol=US$

# ########## SOFTWARE ########## 
#
# The name and vendor of your EJB container (J2EE Application Server).
#
system.sw.EJB_Container.name=WebSphere 5.0.1 Application Server, Network Deployment
system.sw.EJB_Container.vendor=IBM Corporation

# The availability date of the EJB container (J2EE Application Server).
# This date must be in the form Mon-YYYY to be read by the reporter 
# correctly.
#
system.sw.EJB_Container.available=May-2003

# The total number of instances of the EJB container (J2EE Application 
# Server) as required in Run Rules section 5.4.1.1.
#
system.sw.EJB_Container.instances=2

# The date (in Mon-YYY) format) that the EJB container (J2EE Application 
# Server) passed the CTS as required in Run Rules section 5.4.3.
#
system.sw.EJB_Container.date_passed_CTS=May-2003

# The protocol used by the Driver to communicate with the SUT 
# (e.g. RMI/IIOP) as required in Run Rules section 4.5.4.
#
system.sw.EJB_Container.protocol=RMI/IIOP

# The tuning information for the EJB container (J2EE Application Server)
# as required in Run Rules section 5.4.1. Also, if there are any 
# non-transparent optimizations used to avoid ejbStore operations on
# entity beans, if should be documented here (as required in the Run
# Rules section 1.5.5).
#
# NOTE: The tuning information is put in the report as is, no wrapping
# is done.  Thus using multiple lines and spacing is encouraged.
#
system.sw.EJB_Container.tuning[0]=EJB Container Cache Size: 8191
system.sw.EJB_Container.tuning[1]=ORB Service Minimum Thread Pool Size: 37
system.sw.EJB_Container.tuning[2]=ORB Service Maximum Thread Pool Size: 37
system.sw.EJB_Container.tuning[3]=ORB Service Custom Properties: 
system.sw.EJB_Container.tuning[4]=com.ibm.CORBA.FragmentSize=0

# The name and vendor of the JVM used to run your 
# EJB container (J2EE Application Server).
#
system.sw.EJB_Container.JVM.name=J2RE 1.3.1 IBM Windows 32 build cn131-20030329
system.sw.EJB_Container.JVM.vendor=IBM Corporation

# The availability date of the JVM used to run your
# EJB container (J2EE Application Server).
#
system.sw.EJB_Container.JVM.available=May-2003

# The tuning information for the JVM used to run your EJB container 
# (J2EE Application Server).  This section should also include the 
# command line used to launch the EJB container if appropriate.
#
# NOTE: The tuning information is put in the report as is, no wrapping
# is done.  Thus using multiple lines and spacing is encouraged.
#
system.sw.EJB_Container.JVM.tuning[0]=Initial Heap Size: 1024
system.sw.EJB_Container.JVM.tuning[1]=Maximum Heap Size: 1024

# The name and the vendor for the web container that runs the Supplier Domain.
#
system.sw.Web_Container.Supplier_Domain.name=WebSphere 5.0.1 Application Server, Network Deployment
system.sw.Web_Container.Supplier_Domain.vendor=IBM Corporation

# The availability date of the web container that runs the Supplier Domain.
#
system.sw.Web_Container.Supplier_Domain.available=May-2003

# Tuning information for the web container that runs the Supplier Domain.
#
# NOTE: The tuning information is put in the report as is, no wrapping
# is done.  Thus using multiple lines and spacing is encouraged.
#
system.sw.Web_Container.Supplier_Domain.tuning[0]=Web Container Minimum Thread Pool Size: 10
system.sw.Web_Container.Supplier_Domain.tuning[1]=Web Container Maximum Thread Pool Size: 30
system.sw.Web_Container.Supplier_Domain.tuning[2]=
system.sw.Web_Container.Supplier_Domain.tuning[3]=Note: Secondary nodes used Web Container Minimum and Maximum Thread 
system.sw.Web_Container.Supplier_Domain.tuning[4]=Pool Sizes of 1 and 5 respectively.

# The name and vendor of the JVM used to run your 
# web container that runs the Supplier Domain.
#
system.sw.Web_Container.Supplier_Domain.JVM.name=J2RE 1.3.1 IBM Windows 32 build cn131-20030329
system.sw.Web_Container.Supplier_Domain.JVM.vendor=IBM Corporation

# The availability date of the JVM used to run your 
# web container that runs the Supplier Domain.
#
system.sw.Web_Container.Supplier_Domain.JVM.available=May-2003

# Tuning information for the JVM used to run your
# web container that runs the Supplier Domain.
#
# NOTE: The tuning information is put in the report as is, no wrapping
# is done.  Thus using multiple lines and spacing is encouraged.
#
system.sw.Web_Container.Supplier_Domain.JVM.tuning[0]=Initial Heap Size: 1024
system.sw.Web_Container.Supplier_Domain.JVM.tuning[1]=Maximum Heap Size: 1024

# The name and the vendor for the web container that runs the Emulator.
#
system.sw.Web_Container.Emulator.name=WebSphere 5.0.1 Application Server, Network Deployment
system.sw.Web_Container.Emulator.vendor=IBM Corporation

# The availability date of the web container that runs the Emulator.
#
system.sw.Web_Container.Emulator.available=May-2003

# Tuning information for the web container that runs the Emulator.
#
# NOTE: The tuning information is put in the report as is, no wrapping
# is done.  Thus using multiple lines and spacing is encouraged.
#
system.sw.Web_Container.Emulator.tuning[0]=Web Container Minimum Thread Pool Size: 50
system.sw.Web_Container.Emulator.tuning[1]=Web Container Maximum Thread Pool Size: 50
system.sw.Web_Container.Emulator.tuning[2]=Web Container Growable Thread Pool: true

# The name and the vendor for the JVM used to run your
# web container that runs the Emulator.
#
system.sw.Web_Container.Emulator.JVM.name=J2RE 1.3.1 IBM Windows 32 build cn131-20030329
system.sw.Web_Container.Emulator.JVM.vendor=IBM Corporation

# The availability date of the JVM used to run your 
# web container that runs the Emulator.
#
system.sw.Web_Container.Emulator.JVM.available=May-2003

# Tuning information for the JVM used to run your
# web container that runs the Emulator.
#
# NOTE: The tuning information is put in the report as is, no wrapping
# is done.  Thus using multiple lines and spacing is encouraged.
#
system.sw.Web_Container.Emulator.JVM.tuning[0]=Initial Heap Size: 256 
system.sw.Web_Container.Emulator.JVM.tuning[1]=Maximum Heap Size: 512

# The name and the vendor for the database software.
#
system.sw.DB.name=DB2 Universal Database v8.1 FP3, Workgroup Server Unlimited Edition
system.sw.DB.vendor=IBM Corporation

# The availability date of the database software.
#
system.sw.DB.available=Aug-2003

# Tuning information for the database software.
#
# NOTE: The tuning information is put in the report as is, no wrapping
# is done.  Thus using multiple lines and spacing is encouraged.
#
system.sw.DB.tuning[0]=The db2tune.bat script included within the FDA was used to modify the configuration
system.sw.DB.tuning[1]=for the specdb database and associated database manager. This configuration information
system.sw.DB.tuning[2]=is also provided by the following files in the FDA.
system.sw.DB.tuning[3]=
system.sw.DB.tuning[4]=db2set.txt
system.sw.DB.tuning[5]=dbm_config.txt
system.sw.DB.tuning[6]=specdb_config.txt


# The name and the vendor for the JDBC software.
#
system.sw.JDBC.name=DB2 v8.1 Type 2 JDBC Driver (08.01.0002)
system.sw.JDBC.vendor=IBM Corporation

# The availability date of the JDBC software.
#
system.sw.JDBC.available=Aug-2003

# Tuning information for the database software.
#
# NOTE: The tuning information is put in the report as is, no wrapping
# is done.  Thus using multiple lines and spacing is encouraged.
#
system.sw.JDBC.tuning[0]=DB2 v.8 Type 2 JDBC Driver
system.sw.JDBC.tuning[1]=	Implementation class:   COM.ibm.db2.jdbc.DB2ConnectionPoolDataSource
system.sw.JDBC.tuning[2]=
system.sw.JDBC.tuning[3]=SPECDB Datasource
system.sw.JDBC.tuning[4]=       JNDI Name:              jdbc/SPECDB
system.sw.JDBC.tuning[5]=       Minimum pool size:      48       
system.sw.JDBC.tuning[6]=       Maximum pool size:      48
system.sw.JDBC.tuning[7]=       Statement cache size:   51
system.sw.JDBC.tuning[8]=
system.sw.JDBC.tuning[9]=SPECUtilDB Datasource
system.sw.JDBC.tuning[10]=       JNDI Name:              jdbc/SPECUtilDB
system.sw.JDBC.tuning[11]=       Minimum pool size:      10       
system.sw.JDBC.tuning[12]=       Maximum pool size:      10
system.sw.JDBC.tuning[13]=       Statement cache size:   5

# The name and vendor of any additional software used in your SUT.
#
# NOTE: if there are more than one pieces of additional software 
# that needs to be described, select one for this section and put
# the name, vendor, availability, and tuning information in the 
# "notes" section. If no other software needs to be documented,
# leave this section blank.
#
system.sw.other.name=
system.sw.other.vendor=

# The availability date of the other software.
#
system.sw.other.available=

# Tuning information for the other software.
#
# NOTE: The tuning information is put in the report as is, no wrapping
# is done.  Thus using multiple lines and spacing is encouraged.
#
system.sw.other.tuning[0]=

# ########## HARDWARE ########## 
#
# The label for hardware being described.  This should be a description 
# of what function the hardware is performing (for example "J2EE 
# Application Server").  It may seem strange to have to specify these 
# labels, but the hardware section of the report has to be flexable
# to support a wide variety of hardware configurations (especially in
# distributed mode). With this design, you can specify as many pieces
# of hardware as necessary to describe your SUT and load drivers.
#
system.hw.label[0]=J2EE Application Server

# The operating system name and vendor running on this hardware.
#
system.hw.OS.name[0]=Windows 2000 Server
system.hw.OS.vendor[0]=Microsoft Corporation

# The operating system availability date. This date must be in the 
# form Mon-YYYY to be read by the reporter correctly.
#
system.hw.OS.available[0]=Jun-2003

# The hardware availability date. This date must be in the 
# form Mon-YYYY to be read by the reporter correctly.
#
system.hw.available[0]=Jun-2003

# The vendor name and the vendor URL of this system.
#
system.hw.vendor[0]=IBM Corporation
system.hw.vendor.URL[0]=http://www.ibm.com/

# The model number for the system.
#
system.hw.model[0]=IBM eServer xSeries x360

# The amount of physical RAM in the system, IN MEGABYTES.
# DO NOT use "MB" or "GB", as it will interfer with SPEC's use
# of this field.
#
system.hw.memory[0]=3072

# The type of processor in the system.
#
system.hw.processor[0]=Intel Xeon MP

# The speed of the chip, in MegaHertz. DO NOT use "MHz" or "GHz", as it
# will interfer with SPEC's use of this field.
#
system.hw.MHz[0]=2800

# The amount of level 1 cache, for both instruction (I) and data (D)
# on each CPU.
#
system.hw.L1_cache[0]=12KBI+8KBD

# The amount of level 2 cache on each CPU.
#
system.hw.L2_cache[0]=512KB

# The amount of level 3 (or above) cache on each CPU.
# If there is no other cache, leave this field blank.
#
system.hw.other_cache[0]=2048KB

# The number of CPUs in the system. This field should be an integer.
#
system.hw.nCPU[0]=4

# The network interface(s) used on this system.
#
system.hw.network_interface[0]=1000BASE-TX (Gigabit) Ethernet

# Size and type of disk(s) used by the system.
#
# Note: For systems with a complex description for the disks,
# simlpy indicate "see notes" and put the decription in the
# notes section below.
#
system.hw.disk[0]=36.4GB Ultra 160 SCSI

# The file system used by the system.
#
system.hw.file_system[0]=NTFS

# The number of systems (with this decription) used in the SUT.
# This field should be an integer.
#
system.hw.nSystems[0]=2

# Any other hardware that is performance related.  That is, any
# non-standard piece of hardware necessary to reproduce this result.
#
system.hw.other[0]=

# Any additional information on the hardware (including OS tuning). 
#
# NOTE: The notes are put in the report as is, no wrapping
# is done.  Thus using multiple lines and spacing is encouraged.
# Even if you only have one line of notes, the field name still
# must be in the form [n][0].  Specifying 
#     system.hw.notes[0] = "Foo"
# just won't work.
#

system.hw.notes[0][0]=The following parameters were added to the Windows registry:
system.hw.notes[0][1]=
system.hw.notes[0][2]=[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\"TcpTimedWaitDelay"=dword:0000001e]
system.hw.notes[0][3]=[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\"MaxUserPort"=dword:0000fffe]

 
# This sample file provides three hardware descriptions as an example
# of a typical configuration.  You should modify it as nessary to
# describe your SUT.
#
# Note: The benchmark does not require that the database server be run
# on a separate machine, this is just an example where it was. 
# 
system.hw.label[1]=Database Server
system.hw.OS.name[1]=Windows 2000 Advanced Server 
system.hw.OS.vendor[1]=Microsoft Corporation
system.hw.OS.available[1]=Jun-2003
system.hw.MHz[1]=2800
system.hw.L1_cache[1]=12KBI+8KBD
system.hw.L2_cache[1]=512KB
system.hw.other_cache[1]=2048KB (L3 cache)
system.hw.available[1]=Jun-2003
system.hw.disk[1]=18.2GB Ultra 160 SCSI
system.hw.file_system[1]=NTFS
system.hw.memory[1]=3072
system.hw.model[1]=IBM eServer xSeries x360
system.hw.nCPU[1]=2
system.hw.nSystems[1]=1
system.hw.network_interface[1]=(2)1000BASE-TX (Gigabit) Ethernet
system.hw.other[1]=(2) EXP300 Storage Expansion Units with a total of 21 18GB Ultra 160 SCSI disks 
system.hw.processor[1]=Intel Xeon MP
system.hw.vendor[1]=IBM Corporation
system.hw.vendor.URL[1]=http://www.imb.com/
system.hw.notes[1][0]=The following parameters were added to the Windows system registry:
system.hw.notes[1][1]=
system.hw.notes[1][2]=[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\Tcpip\\Parameters\\"TcpTimedWaitDelay"=dword:0000001e]
system.hw.notes[1][3]=[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\Tcpip\\Parameters\\"MaxUserPort"=dword:0000fffe]
system.hw.notes[1][4]=[HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Session Manager\\Memory Management\\"LargeSystemCache"=dword:00000000] 
system.hw.notes[1][5]=

# Please include a description of the systems used to generate
# the load.  While not considered part of the SUT, it is required
# that you provide this information in your results.
#
# Note: the load drivers can appear anywhere in your list of 
# hardware, but PLEASE make sure that your numbering is consistent 
# and sequential so the reporter can format the results properly.
#
system.hw.label[2]=Load Driver
system.hw.OS.name[2]=Windows 2000 Server
system.hw.OS.vendor[2]=Microsoft Corporation
system.hw.OS.available[2]=Jun-2003
system.hw.MHz[2]=900
system.hw.L1_cache[2]=16KBI+16KBD (on chip)
system.hw.L2_cache[2]=2MB (on chip)
system.hw.other_cache[2]=
system.hw.available[2]=Jun-2000
system.hw.disk[2]=18GB Ultra 160 SCSI
system.hw.file_system[2]=NTFS
system.hw.memory[2]=4096
system.hw.model[2]=IBM eServer xSeries x350
system.hw.nCPU[2]=4
system.hw.nSystems[2]=1
system.hw.network_interface[2]=1000BASE-TX (Gigabit) Ethernet
system.hw.other[2]=
system.hw.processor[2]=Pentium III Xeon
system.hw.vendor[2]=IBM Corporation
system.hw.vendor.URL[2]=http://www.ibm.com
system.hw.notes[2][0]=The load driver utilized the IBM JDK included with WebSphere 5.0.1
system.hw.notes[2][1]=Application Server (J2RE 1.3.1 IBM Windows 32 build cn131-20030329).

# BENCHMARK REQUIREMENTS DOCUMENTATION
#
# NOTE: The notes are put in the report as is, no wrapping is done.  
# Thus using multiple lines and spacing is encouraged.
#
# This is where you would document any changes that were made to
# the benchmark schema as required in the Run Rules, section 2.4
# and section 5.4.6.
#
benchmark.schema_modifications[0]=The scripts used to create the database are located within the FDA. Two additional
benchmark.schema_modifications[1]=indicies were added for the M_LargeOrder table in the manufacturing domain.
benchmark.schema_modifications[2]=The DDL to create these indicies are included in the FDA /schema/sql directory.


# This is where you would document any changes that were made to
# the load programs as required in the Run Rules, and section 2.4 
# and section 5.4.7.
#
benchmark.load_program_modifications[0]=No changes were made to the load program.


# This is where you would document and changes that were made to
# the reference beans as required in the Run Rules, section 2.5
# and section 5.4.10.
#
benchmark.reference_bean_modifications[0]=No modifications were made to the reference beans.

# This is where you would document what persistence mode was used
# as required in the Run Rules, section 5.4.9.
#
benchmark.persistence_mode_used[0]=All beans were deployed using Container Managed Persistence (CMP).

# This is where you would document how the isolation requirements
# were met as required in the Run Rules, section 5.4.16.
#
benchmark.isolation_requirement_info[0]=All beans were deployed with the isolation level set to REPEATABLE_READ. DB2
benchmark.isolation_requirement_info[1]=translates this isolation level to Read Stability.  Read Stability ensures
benchmark.isolation_requirement_info[2]=that all rows referenced in a transaction have a read-lock associated with
benchmark.isolation_requirement_info[3]=them to ensure that other transactions cannot change the rows until the first
benchmark.isolation_requirement_info[4]=referencing transaction completes. 

# This is where you would document how your system satisfies the
# durability requirements for the benchmark as required in the
# Run Rules, section 5.4.17.
#
benchmark.durability_requirement_info[0]=To ensure database durability, RAID-1E enhanced disk mirroring was used for
benchmark.durability_requirement_info[1]=the database log files.

# This is where you would document how your system satisfies the
# storage requirements for the benchmark as required in the
# Run Rules, section 5.5.9.
#
benchmark.storage_requirement_info[0]=Over the course of a 45 minute run at an injection rate of 260, database storage
benchmark.storage_requirement_info[1]=increased  150.5 MB. Given a linear scale, an eight hour run at the same injection
benchmark.storage_requirement_info[2]=rate would increase storage 1606 MB. The disk array enclosure was configured  
benchmark.storage_requirement_info[3]=with 118 GB of disk storage. 

# This is where you would document how your system adheres to
# Section 18.2.3 of the EJB 1.1 specification (Argument passing
# semantics) as required in the Run Rules, section 5.4.1.2.
#
benchmark.argument_passing_semantics[0]=WebSphere 5.0.1 Application Server uses pass-by-value semantics by default.


# Info for other Run Rules should be included here, such as
#   - section 5.4.19 (xerces.jar), 
#   - section 5.5.1 (network routing) or 
#   - section 5.5.5 (load balancing by the drivers).
#
benchmark.other[0]=This submission used the xerces.jar (version - XML4J 4.0.10) provided with WebSphere Application Server 5.0.1.


# Any additional notes for this submission should be included here.
#
# This section should contain any errors in the Driver error logs (as 
# required in the Run Rule section 2.8 and 5.5.8).
#
notes[0]=No errors were encoutered in the driver error logs.

# This is where you would document the results from the reproducibility
# run as required in the Run Rules section 2.9.2.
#
result.reproducibility_run.tops=448.81

# This is here you would document the injection rate used when the
# database was loaded as required in the Run Rules section 5.4.4.
#
benchmark.load.injection_rate=260

# BENCHMARK RESULTS
#
# The load driver will generate a "result.props" that contains the results from your
# run that should be appended to this report. Below is an example of the fields from
# the result.props file.
#

result.orders.new_order.count=232158
result.orders.change_order.count=93478
result.orders.order_status.count=93287
result.orders.customer_status.count=46622
result.orders.new_order.resp_time.avg=0.773
result.orders.new_order.resp_time.max=5.172
result.orders.new_order.resp_time.90p=1.900
result.orders.change_order.resp_time.avg=0.408
result.orders.change_order.resp_time.max=2.250
result.orders.change_order.resp_time.90p=0.800
result.orders.order_status.resp_time.avg=0.197
result.orders.order_status.resp_time.max=1.828
result.orders.order_status.resp_time.90p=0.500
result.orders.customer_status.resp_time.avg=0.262
result.orders.customer_status.resp_time.max=1.828
result.orders.customer_status.resp_time.90p=0.600
result.manufacturing.workorders.count=341066
result.manufacturing.resp_time.avg=2.232
result.manufacturing.resp_time.max=5.094
result.manufacturing.resp_time.90p=3.000
benchmark.version=SPECjAppServer2002 v1.14

config.injection_rate=260
config.ramp_up_seconds=600
config.ramp_down_seconds=300
config.steady_state_seconds=1800
config.trigger_time_seconds=276
config.order_agents=1
config.mfg_agents=1

result.start_time=Tue Jun 10 17:01:07 EDT 2003

