Scribd
Upload
39 views10 pages

L36 - IO Perf Measures

The document discusses various measures for evaluating I/O performance in systems. It outlines that I/O performance depends on many factors like the disk technology, memory system, and file system. It also describes different benchmarks for measuring performance, including transaction processing benchmarks from the Transaction Processing Council and file system and web server benchmarks from SPEC. The document concludes with discussing designing an I/O system to meet latency and bandwidth constraints by identifying the weakest link and configuring the system accordingly.

Uploaded by

Jaisaiarun P Srinivasan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
39 views10 pages

L36 - IO Perf Measures

The document discusses various measures for evaluating I/O performance in systems. It outlines that I/O performance depends on many factors like the disk technology, memory system, and file system. It also describes different benchmarks for measuring performance, including transaction processing benchmarks from the Transaction Processing Council and file system and web server benchmarks from SPEC. The document concludes with discussing designing an I/O system to meet latency and bandwidth constraints by identifying the weakest link and configuring the system accordingly.

Uploaded by

Jaisaiarun P Srinivasan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 10

I/O Performance Measures

Dr. E. Papanasam
SoC
I/O Performance Measures
• I/O performance depends on many aspects of the system
• Different applications stress different aspects of the I/O system
• A design can make complex tradeoffs between response time
and throughput
• Making it impossible to measure just one aspect in isolation
• Handling a request as early as possible generally minimizes
response time
• Greater throughput can be achieved if we try to handle related
requests together
I/O Performance Measures
• Measurements proposed for determining the performance of
storage systems
• These benchmarks are affected by a variety of system features,
including
– Disk technology,
– way disks are connected,
– memory system,
– processor, and
– file system provided by the operating system
I/O Performance Measures
• The performance of I/O systems depends on the rate at which the
system transfers data
• The transfer rate depends on clock rate in GHz = 109 cycles per sec
• The transfer rate is usually quoted in GB/sec
• In I/O systems, GBs are measured using base 10 (i.e., 1 GB = 109 =
1,000,000,000 bytes)
• In main memory base 2 is used (i.e., 1 GB = 230 = 1,073,741,824
bytes)
• In addition to adding confusion, this difference introduces the need
to convert between base 10 (1K = 1000) and base 2 (1K = 1024)
• Because many I/O accesses are for data blocks that have a size that
is a power of 2
• Treating the two measures as if the units were identical introduces
a small error
Transaction processing
• A type of application involves handling short operations (called
transactions) that typically require both I/O and computation
• TP applications typically have both response time requirements
and a performance measurement based on the throughput of
transactions
• TP applications are chiefly concerned with
– I/O rate, measured as the number of accesses per second,
– as opposed to data rate, measured as bytes of data per second
• Transaction Processing Council (TPC) benchmarks
– TPC-APP: B2B application server and web services
– TPC-C: on-line order entry environment
– TPC-E: on-line transaction processing for brokerage firm
– TPC-H: decision support — business oriented ad-hoc queries
Transaction processing council
• All the TPC benchmarks measure performance in transactions
per second
• Include a response time requirement, so that throughput
performance is measured only when the response time limit is
met
• To model real-world systems, higher transaction rates are also
associated with larger systems, both in terms of users and the
size of the database to which the transactions are applied
• Hence, storage capacity must scale with performance
• Finally, the system cost for a benchmark system must also be
included, allowing accurate comparisons of cost/ performance
File System and Web I/O Benchmarks
• In addition to processor benchmarks, SPEC offers both a file server
benchmark (SPECSFS) and a Web server benchmark (SPECWeb)
• SPECSFS
– Benchmark for measuring NFS (Network File System)
performance using a script of file server requests
– Tests the performance of the I/O system, including both disk
and I/O, as well as the processor
– Throughput-oriented benchmark but with important response
time requirements
• SPECWeb is a Web server benchmark that simulates multiple
clients requesting both static and dynamic pages from a server, as
well as clients posting data to the server
• SPECPower measures power and performance characteristics of
small servers
Designing an I/O system
• Two primary types of specifications that designers encounter in
I/O systems:
– latency constraints and bandwidth constraints
• In both cases, knowledge of the traffic pattern affects the design
and analysis
• Latency constraints involve ensuring that the latency to complete
an I/O operation is bounded by a certain amount
• Determining the latency on an unloaded system is relatively easy,
since it involves tracing the path of the I/O operation and
summing the individual latencies
• Finding the average latency (or distribution of latency) under a
load is much harder
Designing an I/O system
• Such problems are tackled either by queuing theory (when
the behavior of the workload requests and I/O service times
can be approximated by simple distributions) or by
simulation (when the behavior of I/O events is complex)
• Given a workload designing an I/O system to meet a set of
bandwidth constraints is the other typical problem designers
face
• Alternatively, the designer may be given a partially
configured I/O system and be asked to balance the system to
maintain the maximum bandwidth achievable, as dictated by
the preconfigured portion of the system
• This latter design problem is a simplified version of the first
General approach to designing I/O
system
• 1. Find the weakest link in the I/O system, which is the
component in the I/O path that will constrain the design
• Depending on the workload, this component can be anywhere,
including the processors, the memory system, the I/O
controllers, or the devices
• Both the workload and configuration limits may dictate where
the weakest link is located
• 2. Configure this component to sustain the required
bandwidth
• 3. Determine the requirements for the rest of the system and
configure them to support this bandwidth

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy