tx100 s1 performance report (en)

8/7/2019 Tx100 s1 Performance Report (en)

1/19

Abstract

This document contains a results summary of the benchmarks executed for the PRIMERGY TX100 S1. Inaddition to the benchmark results, an explanation has been included for each benchmark and for thebenchmark environment.

Contents

Document history.................................................................................................................................... 2

Technical Data........................................................................................................................................ 3

SPECcpu2006........................................................................................................................................ 4

SPECjbb2005......................................................................................................................................... 9

SPECpower_ssj2008............................................................................................................................ 12

StorageBench ....................................................................................................................................... 15

Literature............................................................................................................................................... 19

Contact.................................................................................................................................................. 19

Version 3.0January 2010

Pages 19

Performance ReportPRIMERGY TX100 S1


2/19

White Paper Performance Report PRIMERGY TX100 S1 Version: 3.0, January 2010

Fujitsu Technology Solutions 2009-2010 Page 2 (19)

Document history

Version 1.0

First report version including the benchmark chapters

SPECcpu2006Measurements with Celeron 430 and 450, Pentium Dual-Core E5200 and Xeon X3330

SPECjbb2005Measurement with Xeon X3380

SPECpower_ssj2008Measurement with Xeon L3360 and 1 x SATA 3.5 7200rpm

StorageBenchMeasurements with Onboard SATA ICH9R Controller

Version 2.0

In all benchmark chapters: foot note regarding availability of components added

Updated benchmark chapters:

SPECcpu2006

Measurements with Pentium Dual-Core E6300, Core 2 Duo E7400 and E7600 and Xeon E3120 andX3220

SPECjbb2005Presentation of the measurement result with Xeon X3380 as a record in the class of mono-socketservers

Version 2.1

Updated benchmark chapters:

SPECcpu2006Measurements with Core 2 Duo E7300 and Xeon E3110, L3360 and X3380

Version 3.0

Updated benchmark chapters: SPECcpu2006

Measurements with Pentium Dual-Core E5400 and E6500

SPECpower_ssj2008corrections


3/19



Technical Data

The PRIMERGY TX100 S1 is an energy saving mono socket Tower Server. It includes the Intel 3200 chipset, a Celeron, Pentium Dual-Core, Core 2 Duo or Xeon processor, up to 8 GB PC2-6400 DDR2-SDRAM, abus with 667, 800, 1067 or 1333 MHz timing - depending on the processor used, an Intel 82566DM 1-GbitLAN controller, an Intel ICH9R 6-Port SATA controller, a SAS RAID controller (optionally), up to four 3 .5

SATA hard disks and four PCI slots (2 x PCIe x8, 1 x PCIe x4 and 1 x PCI 32-bit/33 MHz).

SeeData sheet PRIMERGY TX100 S1for detailed technical information.
http://docs.ts.fujitsu.com/dl.aspx?id=1ad5ecab-8b9e-4ef4-acda-233326f6f822http://docs.ts.fujitsu.com/dl.aspx?id=1ad5ecab-8b9e-4ef4-acda-233326f6f822http://docs.ts.fujitsu.com/dl.aspx?id=1ad5ecab-8b9e-4ef4-acda-233326f6f822http://docs.ts.fujitsu.com/dl.aspx?id=1ad5ecab-8b9e-4ef4-acda-233326f6f822


4/19



SPECcpu2006

Benchmark description

SPECcpu2006 is a benchmark to measure system efficiency during integer and floating point operations. Itconsists of an integer test suite containing 12 applications and a floating point test suite containing 17applications which are extremely computing-intensive and concentrate on the CPU and memory. Othercomponents, such as disk I/O and network, are not measured by this benchmark.

SPECcpu2006 is not bound to a specific operating system. The benchmark is available as source code andis compiled before the actual benchmark. Therefore, the compiler version used and its optimization settingshave an influence on the measurement result.

SPECcpu2006 contains two different methods of performance measurement: The first method(SPECint2006 and SPECfp2006) determines the time required to complete a single task. The secondmethod (SPECint_rate2006 and SPECfp_rate2006) determines the throughput, i.e. how many tasks can becompleted in parallel. Both methods are additionally subdivided into two measuring runs, "base" and "peak",which differ in the way the compiler optimization is used. The "base" values are always used when resultsare published, the "peak" values are optional.

Benchmark Arithmetic TypeCompileroptimization

Measuringresult

Application

SPECint2006 integer peak aggressivespeed single threaded

SPECint_base2006 integer base conservative

SPECint_rate2006 integer peak aggressivethroughput multithreaded

SPECint_rate_base2006 integer base conservative

SPECfp2006 floating point peak aggressivespeed single threaded

SPECfp_base2006 floating point base conservative

SPECfp_rate2006 floating point peak aggressivethroughput multithreadedSPECfp_rate_base2006 floating point base conservative

The results represent the geometric mean of normalized ratios determined for the individual benchmarks.Compared with the arithmetic mean, the geometric mean results in the event of differingly high single resultsin a weighting in favor of the lower single results. Normalized means measuring how fast the test systemruns in comparison to a reference system. The value of 1 was determined for the SPECint_base2006,SPECint_rate_base2006, SPECfp_base2006 and SPECfp_rate_base2006 results of the reference system.Thus a SPECint_base2006 value of 2 means for example that the measuring system has executed thisbenchmark approximately twice as fast as the reference system. A SPECfp_rate_base2006 value of 4means that the measuring system has executed this benchmark about 4/[# base copies] times as fast as thereference system. # base copies here specifies how many parallel instances of the benchmark have beenexecuted.

We do not submit all SPECcpu2006 measurements for publication at SPEC. So not all results appear onSPECs web sites. As we archive the log data for all measurements, we are able to prove the correctrealization of the measurements any time.

SPEC, SPECint, SPECfp and the SPEC logo are registered trademarks of the Standard PerformanceEvaluation Corporation (SPEC).


5/19



Benchmark results

The PRIMERGY TX100 S1 was measured with seven different processor versions:

Celeron 430 and 450(Conroe, 1 core per chip)

Pentium Dual-Core E5200 and E5400

(Allendale, 2 cores per chip)

Pentium Dual-Core E6300 and E6500(Wolfdale, 2 cores per chip)

Core 2 Duo E7300, E7400 and E7600(Wolfdale, 2 cores per chip)

Xeon E3110 and E3120(Wolfdale, 2 cores per chip)

Xeon X3220(Kentsfield, 4 cores per chip)

Xeon X3330, L3360 and X3380(Yorkfield, 4 cores per chip)

The following tables show results, in which all benchmark programs were compiled with the Intel C++/Fortrancompiler 11.0 and run under SUSE Linux Enterprise Server 10 SP2 (64-bit).

Processor Cores GHz L2 cache FSB TDP SPECint_base2006 SPECint2006

Celeron 430 1 1.80 MB per chip 800 MHz 35 watt 11.6 12.7


Processor Cores GHz L2 cache FSB TDP SPECint_rate_base2006 SPECint_rate2006

Celeron 430 1 1.80 MB per chip 800 MHz 35 watt


Pentium Dual-CoreE5200 2 2500 2 MB per chip 800 MHz 65 watt 31.4 33.4

Pentium Dual-CoreE5400

2 2700 2 MB per chip 800 MHz 65 watt 33.0 35.0





Core 2 Duo E7300 2 2667 3 MB per chip 1067 MHz 65 watt 36.2 38.7



Xeon E3110 2 3000 6 MB per chip 1333 MHz 65 watt 43.6 46.9


Xeon X3220 4 2400 8 MB per chip 1067 MHz 105 watt 61.4 65.7


Xeon L3360 4 2833 12 MB per chip 1333 MHz 65 watt 75.9 81.3



6/19




7/19



Processor Cores GHz L2 cache FSB TDP SPECfp_base2006 SPECfp2006



Processor Cores GHz L2 cache FSB TDP SPECfp_rate_base2006 SPECfp_rate2006













Core 2 Duo E7600 2 3067 3 MB per chip 1067 MHz 65 watt 31.2 32.2Xeon E3110 2 3000 6 MB per chip 1333 MHz 65 watt 33.4 34.6




Xeon L3360 4 2833 12 MB per chip 1333 MHz 65 watt 49.4 51.2



8/19



Benchmark environment

All SPECcpu2006 measurements were performed on a PRIMERGY TX100 S1 with the following hardwareand software configuration:

Hardware

Model PRIMERGY TX100 S1

CPU

Celeron 430 and 450Pentium Dual-Core E5200, E5400, E6300 and E6500Core 2 Duo E7300, E7400 and E7600Xeon E3110, E3120, X3220, X3330, L3360 and X3380

Number of chips

Celeron 430, 450: 1 chip, 1 core, 1 core per chipPentium Dual-Core E5200, E5400, E6300, E6500,Core 2 Duo E7300, E7400, E7600,Xeon E3110, E3120: 1 chip, 2 cores, 2 cores per chipXeon X3220, X3330, L3360, X3380: 1 chip, 4 cores, 4 cores per chip

Primary Cache 32 kB instruction + 32 kB data on chip, per core

Secondary Cache

Celeron 430, 450: MB (I+D) on chip, per chipPentium Dual-Core E5200, E5400, E6300, E6500: 2 MB (I+D) on chip, per chipCore 2 Duo E7300, E7400, E7600: 3 MB (I+D) on chip, per chipXeon E3110, E3120, X3330: 6 MB (I+D) on chip, per chipXeon X3220: 8 MB (I+D) on chip, per chipXeon L3360, X3380: 12 MB (I+D) on chip, per chip

Other Cache none

Memory 4 x 2 GB PC2-6400 DDR2-SDRAM

Software

Operating System SUSE Linux Enterprise Server 10 SP2 (64-bit)

Compiler Intel C++/Fortran Compiler 11.0

Some components may not be available in all countries / sales regions.


9/19


10/19



A compliant benchmark run consists of a sequence of measuring points with an increasing number of ware-houses (and thus of threads) with the number in each case being increased by one warehouse. The run isstarted at one warehouse up through 2*MaxWhm but not less than 8 warehouses. MaxWhm is the number ofwarehouses with the highest operation rate per second the benchmark expects. Per default the benchmarkequates MaxWH with the number of CPUs visible by the operating system.

The metrics bops is the arithmetic average of all measured operation rates with between MaxWhm ware-

houses and 2*MaxWhm warehouses.

Benchmark results

In June 2009 the PRIMERGY TX100 S1 was measured with a memory configuration with 8 GB PC2-6400DDR2-SDRAM with one Xeon X3380 processor. The measurement was taken under Windows Server 2008Enterprise x64 Edition SP2. Two instances of JRockit(R) 6 R28.0.0 from Oracle were used as JVM for themeasurement.

The PRIMERGY TX100 S1 achieved the best result of all servers with 1 processor and exceeded the pre-

vious front runner in this category by 4%. With both measurements all measured values between 2 and 4warehouses were incorporated in the benchmark result.

Competitive benchmark results stated above reflect results published as of August 5, 2009. The comparison presentedabove is based on the best performing servers with 1 processor currently shipping by IBM and Fujitsu. For the latestSPECjbb2005 benchmark results, visithttp://www.spec.org/jbb2005/results.
http://www.spec.org/jbb2005/resultshttp://www.spec.org/jbb2005/resultshttp://www.spec.org/jbb2005/resultshttp://www.spec.org/jbb2005/results


11/19



Source:http://www.spec.org/jbb2005/results, as of August 5, 2009


The SPECjbb2005 measurement was performed on a PRIMERGY TX100 S1 with the following hardwareand software configuration:

Hardware


CPU Xeon X3380Number of chips 1 chip, 4 cores, 4 cores per chip

Primary Cache 32 kB instruction + 32 kB data on chip, per core

Secondary Cache 12 MB (I+D) on chip, per chip

Other Cache none

Memory 4 x 2 GB PC2-6400 DDR2-SDRAM

Software

Operating System Windows Server 2008 Enterprise x64 Edition SP2

JVM VersionOracle JRockit(R) 6 P28.0.0(build P28.0.0-29-114096-1.6.0_11-20090427-1759-windows-x86_64)

http://www.spec.org/jbb2005/resultshttp://www.spec.org/jbb2005/resultshttp://www.spec.org/jbb2005/resultshttp://www.spec.org/jbb2005/results


12/19



SPECpower_ssj2008*


SPECpower_ssj2008 is the first industry-standard SPEC benchmark that evaluates the power andperformance characteristics of server class computers. With SPECpower_ssj2008, SPEC has defined serverpower measurement standards in the same way they have done for performance.

The benchmark workload represents typical server-side Java business applications. The workload isscalable, multi-threaded, portable across a wide range of operating environments, and economical to run. Itexercises CPUs, caches, memory hierarchy, and the scalability of symmetric multiprocessor systems(SMPs), as well as implementations of the Java Virtual Machine (JVM), Just In Time (JIT) compiler, garbagecollection, threads, and some aspects of the operating system.

SPECpower_ssj2008 reports power consumption forservers at different performance levels from 100-percent to active idle in 10-percent segments over aset period of time. The graduated workload recognizesthe fact that processing loads and power consumptionon servers vary substantially over the course of days orweeks. To compute a power-performance metric acrossall levels, measured transaction throughputs for eachsegment are added together, and then divided by thesum of the average power consumed for each segment.The result is a figure of merit called "overallssj_ops/watt." This ratio gives information about theenergy efficiency of the measured server. Because of itsdefined measurement standard it allows the customersto compare it to other configurations and serversmeasured with SPECpower_ssj2008. The adjoiningdiagram shows a typical graph of aSPECpower_ssj2008 result.

The benchmark runs on a wide variety ofoperating systems and hardwarearchitectures and does not require extensiveclient or storage infrastructure. The minimumequipment for SPEC-compliant testing is twonetworked computers, plus a power analyzerand a temperature sensor. One computer isthe System Under Test (SUT) running any ofthe supported operating systems along withthe JVM installed. The JVM provides the

environment required to run theSPECpower_ssj2008 workload which isimplemented in Java. The other computer isa Collect and Control System (CCS) whichcontrols the operation of the benchmark andcaptures the power, performance andtemperature readings for reporting. Theadjoining diagram gives an overview of thedifferent components of this framework.

* SPEC, SPECpower_ssj2008 and the SPEC logo are registered trademarks of the StandardPerformance Evaluation Corporation (SPEC).


13/19



Benchmark results

In June 2009 the PRIMERGY TX100 S1 was measured with an Intel Xeon L3360 processor and 4 GB ofPC2-6400E DDR2-SDRAM memory. The measurement was taken under Windows Server 2008 Enterprisex64 Edition with SP2 and a JRockit(R) 6 P28.0.0 JVM by Oracle was used.

With the Intel Xeon L3360 processor the PRIMERGY TX100 S1 achieved a world record score of 1,500

overall ssj_ops/watt in the class of 1-socket-servers which exceeded the previous front runner by 17.8%*

.The PRIMERGY TX150 S6 which was measured with the same processor achieved a lower throughput inssj_ops because an earlier version of the JRockit(R) JVM was used. So, the advance of theSPECpower_ssj2008 result of the PRIMERGY TX100 S1 is explained by the lower power consumption at allload levels and the improved throughput in ssj_ops of the Oracle JRockit(R) 6 P28.0.0 JVM.

The adjoining diagram shows the resultgraph of the configuration describedabove, measured with the PRIMERGYTX100 S1. The red horizontal barsshow the performance to power ratio inssj_ops/watt (upper x-axis) for eachtarget load level which are tagged onthe y-axis of the diagram. The blue line

shows the run of the curve for theaverage power consumption (bottom x-axis) at each target load level markedwith a small rhomb.

The diagram shows how the efficiencyof the server decreases with eachtarget load level from 100% to activeidle in 10% segments. The blackvertical line shows the benchmarkresult of 1,500 overall ssj_ops/watt forthe PRIMERGY TX100 S1. This is thequotient of the sum of the transactionthroughputs for each measurementinterval and the sum of the averagepower consumed for eachmeasurement interval.

The following table shows the detailed information for the throughput in ssj_ops, the average powerconsumption in watts and the resulting energy efficiency for each load level of the measured result.

Performance Power Energy Efficiency

Target Load ssj_ops Average Power (W) ssj_ops/watt

100% 212,779 94.7 2,247

90% 193,029 91.2 2,117

80% 169,252 85.6 1,977

70% 148,628 80.3 1,850

60% 128,358 75.5 1,701

50% 107,052 70.7 1,514

40% 86,012 66.4 1,296

30% 63,953 62.0 1,032

20% 42,036 57.2 735

10% 21,366 52.1 410

Active Idle 0 46.2 0

ssj_ops / power = 1,500

* Competitive benchmark results stated above reflect results published as of Jun 17th

, 2009. The comparisonpresented above is based on the most energy efficient 1-socket-servers. For the latestSPECpower_ssj2008 benchmark results, visithttp://www.spec.org/power_ssj2008/results.
http://www.spec.org/power_ssj2008/resultshttp://www.spec.org/power_ssj2008/resultshttp://www.spec.org/power_ssj2008/resultshttp://www.spec.org/power_ssj2008/results


14/19



The configuration was tuned to get the best possible result for this server in terms of performance per watt.The memory configuration with 2 x 2 GB was selected to meet the criteria of best performance at lowestpower consumption by populating only one slot of each available memory channel. This configurationenables the benchmark to use the full potential of the available memory bandwidth and at the same timeconsumes less power than a comparable performance equivalent 4 DIMMs configuration. The most

important factor in the hardware configuration is the right choice of the processor. Processors are the part ofa server which consumes the most power beside the memory subsystem. For the PRIMERGY TX100 S1 thequad-core Intel Xeon L3360 processor with a Thermal Design Power (TDP) of 65 watt showed the bestefficiency score.


The SPECpower_ssj2008 measurement presented here was performed on a PRIMERGY TX100 S1 with thefollowing hardware and software configuration using the ZES Zimmer LMG95 power analyzer:

Hardware


Processor (TDP) Intel Xeon L3360 (65 W)

Number of chips 1 chip, 4 cores per chip

Primary Cache 32 KB instruction + 32 KB data on chip, per core

Secondary Cache 12 MB (I+D) on chip, per chip, 6 MB shared / 2 cores

Other Cache none

Memory 2 x 2 GB PC2-6400E DDR2-SDRAM

Network Interface 1 x 1 GBit LAN Intel 82566DM-2 Gigabit Network Connection (onboard)

Disk Subsystem1 Integrated SATA controller

1 3.5 SATA disk, 250 GB, 7.2 krpm, JBOD

Power Supply Unit 1 x 300 W Fujitsu Technology Solutions S26113-E548-V50-01

SoftwareOperating System Windows Server 2008 Enterprise x64 Edition + SP2

JVM VersionOracle JRockit(R) 6 P28.0.0

(build P28.0.0-29-114096-1.6.0_11-20090427-1759-windows-x86_64)

JVM affinity start /affinity [0x3,0xC]

JVM options-Xms1625m -Xmx1625m -Xns1400m -XXaggressive -Xlargepages -Xgc:genpar -XXcallprofiling -XXgcthreads=2 -XXtlasize:min=4k,preferred=1024k



15/19



StorageBench


To estimate the capability of disk subsystems Fujitsu Technology Solutions defined a benchmark calledStorageBench to compare the different storage systems connected to a system. To do this StorageBenchmakes use of the Iometer measuring tool developed by Intel combined with a defined set of load profiles thatoccur in real customer applications and a defined measuring scenario.

Measuring tool

Since the end of 2001 Iometer has been a project athttp://SourceForge.netand is ported to various plat-forms and enhanced by a group of international developers. Iometer consists of a user interface for Windowssystems and the so-called dynamo which is available for various platforms. For some years now it hasbeen possible to download these two components under Intel Open Source License fromhttp://www.iometer.org/orhttp://sourceforge.net/projects/iometer.

Iometer gives you the opportunity to reproduce the behavior of real applications as far as accesses to IOsubsystems are concerned. For this purpose, you can among other things configure the block sizes to beused, the type of access, such as sequential read or write, random read or write and also combinations ofthese. You can also configure the number of simultaneous accesses ("Outstanding IOs"). As a result Iometer

provides a text file with comma separated values (.csv) containing basic parameters, such as throughput persecond, transactions per second and average response time for the respective access pattern. This methodpermits the efficiency of various subsystems with certain access patterns to be compared. Iometer is in aposition to access not only subsystems with a file system, but also so-called raw devices.

With Iometer it is possible to simulate and measure the access patterns of various applications, but the filecache of the operating system remains disregarded and operation is in blocks on a single test file.

Load profile

The manner in which applications access the mass storage system considerably influences the performanceof a storage system. Examples of various access patterns of a number of applications:

Application Access pattern

Database (data transfer) random, 67% read, 33% write, 8 KB (SQL Server)

Database (log file) sequential, 100% write, 64 KB blocks

Backup sequential, 100% read, 64 KB blocks

Restore sequential, 100% write, 64 KB blocks

Video streaming sequential, 100% read, blocks 64 KB

File server random, 67% read, 33% write, 64 KB blocks

Web server random, 100% read, 64 KB blocks

Operating system random, 40% read, 60% write, blocks 4 KB

File copy random, 50% read, 50% write, 64 KB blocks

From this four distinctive profiles were derived:

Load profile Access Access pattern Blocksize

OutstandingIOs

Loadtool

read write

Streaming sequential 100% 64 KB 3 Iometer

Restore sequential 100% 64 KB 3 Iometer

Database random 67% 33% 8 KB 3 Iometer

File server random 67% 33% 64 KB 3 Iometer

All four profiles were generated with Iometer.
http://sourceforge.net/http://sourceforge.net/http://sourceforge.net/http://www.iometer.org/http://www.iometer.org/http://sourceforge.net/projects/iometerhttp://sourceforge.net/projects/iometerhttp://sourceforge.net/projects/iometerhttp://sourceforge.net/projects/iometerhttp://www.iometer.org/http://sourceforge.net/


16/19



Measurement scenario

In order to obtain comparable measurement results it is important to perform all the measurements in iden-tical, reproducible environments. This is why StorageBench is based, in addition to the load profile describedabove, on the following regulations:

Since real-life customer configurations work only in exceptional situations with raw devices, perfor-

mance measurements of internal disks are always conducted on disks containing file systems. NTFSis used for Windows and ext3 for Linux, even if higher performance could possibly be achieved withother file systems or raw devices.

Hard disks are among the most error-prone components of a computer system. This is why RAIDcontrollers are used in server systems in order to prevent data loss through hard disk failure. Hereseveral hard disks are put together to form a Redundant Array of Independent Disks, known asRAID in short with the data being spread over several hard disks in such a way that all the data isretained even if one hard disk fails except with RAID 0. The most usual methods of organizing harddisks in arrays are the RAID levels RAID 0, RAID 1, RAID 5, RAID 6, RAID 10, RAID 50 andRAID 60. Information about the basics of various RAID arrays is to be found in the paperPerformance Report - Modular RAID for PRIMERGY.

Depending on the number of disks and the installed controller, the possible RAID configurations areused for the StorageBench analyses of the PRIMERGY servers. For systems with two hard disks weuse RAID 1 and RAID 0, for three and more hard disks we also use RAID 1E and RAID 5 and, whereapplicable, further RAID levels provided that the controller supports these RAID levels.

Regardless of the size of the hard disk, a measurement file with the size of 8 GB is always used forthe measurement.

In the evaluation of the efficiency of I/O subsystems, processor performance and memory configura-tion do not play a significant role in todays systems - a possible bottleneck usually affects the harddisks and the RAID controller, and not CPU and memory. Therefore, various configuration alterna-tives with CPU and memory need not be analyzed under StorageBench.

Measurement results

For each load profile StorageBench provides various key indicators: e.g. data throughput in megabytes per

second, in short MB/s, transaction rate in I/O operations per second, in short IO/s, and latency time oralso mean access time in ms. For sequential load profiles data throughput is the normal indicator, whereasfor random load profiles with their small block sizes the transaction rate is normally used. Throughput andtransaction rate are directly proportional to each other and can be calculated according to the formula

Data throughput [MB/s] = Transaction rate [Disk-I/O s-1 ] Block size [MB]

Transaction rate [Disk-I/O s-1 ] = Data throughput [MB/s] / Block size [MB]
http://docs.ts.fujitsu.com/dl.aspx?id=8f6d5779-2405-4cdd-8268-1f948ba050e6http://docs.ts.fujitsu.com/dl.aspx?id=8f6d5779-2405-4cdd-8268-1f948ba050e6http://docs.ts.fujitsu.com/dl.aspx?id=8f6d5779-2405-4cdd-8268-1f948ba050e6


17/19



Benchmark results

The PRIMERGY TX100 S1 server is equipped with the Onboard SATA ICH9R controller. The controller isimplemented directly on the motherboard of the server in the Intel ICH9R chipset and the RAID stack is rea-lized by the server CPU. This controller does not have a controller cache. With the server, which supports a

maximum of four 3" local hard disks, it is possible to configure RAID levels 0, 1 and 10. Various SATA harddisks can be connected to this controller. Depending on the performance required, it is possible to select theappropriate disk subsystem.

The following hard disks can be chosen for the server:

3" SATA hard disks with a capacity of 160 GB, 250 GB and 500 GB (7.2 krpm)

The RAID array defines the way in which data is treated as regards availability. How quickly the data istransferred in the respective RAID array context depends largely on the data throughput of the hard disks.The number of hard disks configured for the measurements in a RAID array was defined depending on theRAID level.

The hard disk cache has influence on disk I/O performance. This is frequently seen as a safety problem inthe event of a power failure and is therefore disabled. Nevertheless, it was for a good reason integrated bythe hard disk manufacturers to increase write performance. The by far larger cache for I/O accesses and

thus a potential safety risk (data loss) in the event of a power failure is situated in the main memory and isadministered by the operating system. To prevent data losses it is advisable to equip the system with anuninterruptible power supply (UPS).

In the test setup two SATA hard disks were configured as a RAID 1 or one SATA hard disk as Single Disk(SD) and connected to the controller. In the measurements all hard disk types currently available for thePRIMERGY TX100 S1 were analyzed. The throughputs of the individual hard disk types in RAID 1 and asSingle Disk are compared below with different access patterns. Since there is no a controller cache, only theimpact of the disk cache was examined in the measurements and the measurements for the hard diskcomparison were in each case performed with and without a disk cache.

The following illustrations show how throughput depends on cache settings. Read throughput for sequentialreading of 64 KB blocks is not dependent on the cache settings. In RAID 1 roughly the same throughput val-

ues are achieved as in the single disk configuration,although RAID 1 offers the benefit of data redundancy.

In contrast, write throughput with sequential accesswith 64 KB blocks largely depends on the cache set-tings. Enabling the disk cache improves the writethroughput by a factor of about 15 in the single diskconfiguration and by a factor 11 in a RAID 1 configura-tion. The much higher write throughput is explained bythe optimized write accesses to the hard disk and theshorter latency times.

Enabling the disk cache leads to an increase inthroughput during random access. However this in-crease is not as noticeable as with sequential writing.With a random access with 64 KB blocks and a singledisk configuration the increase in throughput is about16% and in RAID 1 about 23%.

In the case of random access with 8 KB blocks theincrease in throughput is a little higher than in the casewith random access with 64 KB blocks and is roughly24% with single disk and about 29% with RAID 1.


18/19



Conclusion

The onboard SATA RAID controller offers the user good solution options with a very good price/performanceratio. The onboard SATA controller is implemented directly on the motherboard of the server in the IntelICH9R chipset.

For maximum performance it is advisable, particularly with SATA hard disks or when using a controller

without a controller cache, to enable the hard disk cache. Depending on the disk type used, the increase inperformance is 15-fold. When the hard disk cache is enabled we recommend the use of a UPS.


All the measurements presented here were performed with the hardware and software components listedbelow.

Component Details

Server PRIMERGY TX100 S1

Operating systemWindows Server 2008, Enterprise Edition

Version: 6.0.6001 Service Pack 1 Build 6001

File system NTFS

Measuring tool Iometer 27.07.2006

Measurement data Measurement file of 8 GB

Onboard SATA Controller

Intel ICH9RBIOS: 6.00.R1.01

SATA RAID Mode

Hard Disk SATA, 3", 7.2 krpm Western Digital WD1600AAJS-07M0A0, 160 GB



19/19


Delivery subject to availability, specifications subject to change withoutnotice, correction of errors and omissions excepted.All conditions quoted (TCs) are recommended cost prices in EURO excl. VAT(unless stated otherwise in the text). All hardware and software names usedare brand names and/or trademarks of their respective holders

Published by department:

Enterprise ProductsPRIMERGY ServerPRIMERGY Performance Lab

Internet:http://ts.fujitsu.com/primergy

Extranet:http://partners.ts.fujitsu.com/com/products/serv

Literature

PRIMERGY Systems

http://ts.fujitsu.com/primergy

PRIMERGY TX100 S1

Data sheethttp://docs.ts.fujitsu.com/dl.aspx?id=1ad5ecab-8b9e-4ef4-acda-233326f6f822

PRIMERGY Performance

http://ts.fujitsu.com/products/standard_servers/primergy_bov.html

SPECcpu2006

http://www.spec.org/osg/cpu2006

Benchmark Overview SPECcpu2006http://docs.ts.fujitsu.com/dl.aspx?id=1a427c16-12bf-41b0-9ca3-4cc360ef14ce

SPECjbb2005

http://www.spec.org/jbb2005

Benchmark Overview SPECjbb2005http://docs.ts.fujitsu.com/dl.aspx?id=5411e8f9-8c56-4ee9-9b3b-98981ab3e820

SPECpower_ssj2008

http://www.spec.org/power_ssj2008

Benchmark Overview SPECpower_ssj2008http://docs.ts.fujitsu.com/dl.aspx?id=166f8497-4bf0-4190-91a1-884b90850ee0

StorageBenchPerformance Report Modular RAID for PRIMERGYhttp://docs.ts.fujitsu.com/dl.aspx?id=8f6d5779-2405-4cdd-8268-1f948ba050e6

iometerhttp://www.iometer.org

Contact

PRIMERGY Hardware

PRIMERGY Product Marketing

mailto:[email protected]

PRIMERGY Performance and Benchmarks

mailto:[email protected]
http://ts.fujitsu.com/primergyhttp://ts.fujitsu.com/primergyhttp://partners.ts.fujitsu.com/com/products/servers/primergyhttp://ts.fujitsu.com/primergyhttp://ts.fujitsu.com/primergyhttp://docs.ts.fujitsu.com/dl.aspx?id=1ad5ecab-8b9e-4ef4-acda-233326f6f822http://docs.ts.fujitsu.com/dl.aspx?id=1ad5ecab-8b9e-4ef4-acda-233326f6f822http://ts.fujitsu.com/products/standard_servers/primergy_bov.htmlhttp://ts.fujitsu.com/products/standard_servers/primergy_bov.htmlhttp://www.spec.org/osg/cpu2006http://www.spec.org/osg/cpu2006http://docs.ts.fujitsu.com/dl.aspx?id=1a427c16-12bf-41b0-9ca3-4cc360ef14cehttp://docs.ts.fujitsu.com/dl.aspx?id=1a427c16-12bf-41b0-9ca3-4cc360ef14cehttp://www.spec.org/jbb2005http://www.spec.org/jbb2005http://docs.ts.fujitsu.com/dl.aspx?id=5411e8f9-8c56-4ee9-9b3b-98981ab3e820http://docs.ts.fujitsu.com/dl.aspx?id=5411e8f9-8c56-4ee9-9b3b-98981ab3e820http://www.spec.org/power_ssj2008http://www.spec.org/power_ssj2008http://docs.ts.fujitsu.com/dl.aspx?id=166f8497-4bf0-4190-91a1-884b90850ee0http://docs.ts.fujitsu.com/dl.aspx?id=166f8497-4bf0-4190-91a1-884b90850ee0http://docs.ts.fujitsu.com/dl.aspx?id=8f6d5779-2405-4cdd-8268-1f948ba050e6http://docs.ts.fujitsu.com/dl.aspx?id=8f6d5779-2405-4cdd-8268-1f948ba050e6http://www.iometer.org/http://www.iometer.org/mailto:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]:[email protected]://www.iometer.org/http://docs.ts.fujitsu.com/dl.aspx?id=8f6d5779-2405-4cdd-8268-1f948ba050e6http://docs.ts.fujitsu.com/dl.aspx?id=166f8497-4bf0-4190-91a1-884b90850ee0http://www.spec.org/power_ssj2008http://docs.ts.fujitsu.com/dl.aspx?id=5411e8f9-8c56-4ee9-9b3b-98981ab3e820http://www.spec.org/jbb2005http://docs.ts.fujitsu.com/dl.aspx?id=1a427c16-12bf-41b0-9ca3-4cc360ef14cehttp://www.spec.org/osg/cpu2006http://ts.fujitsu.com/products/standard_servers/primergy_bov.htmlhttp://docs.ts.fujitsu.com/dl.aspx?id=1ad5ecab-8b9e-4ef4-acda-233326f6f822http://ts.fujitsu.com/primergyhttp://partners.ts.fujitsu.com/com/products/servers/primergyhttp://partners.ts.fujitsu.com/com/products/servers/primergyhttp://ts.fujitsu.com/primergy

tx100 s1 performance report (en)

Documents