1. Computer Organization CS224 Fall 2012 Lesson 51

2. Measuring I/O Performance  I/O performance depends on l Hardware: CPU, memory, controllers, buses l Software: operating system, database management system, application l Workload: request rates and patterns  I/O system design can trade-off between response time and throughput l Measurements of throughput often done with constrained response-time §6.7 I/O Performance Measures: …

3. Transaction Processing Benchmarks  Transactions l Small data accesses (a transaction) to a DBMS l Interested in I/O rate (transactions/sec ), not data rate  Measure throughput l Subject to response time limits and failure handling l ACID (Atomicity, Consistency, Isolation, Durability) l Overall cost per transaction  Transaction Processing Council (TPC) benchmarks (www.tpc.org) measure transactions/secwww.tpc.org l TPC-APP: B2B application server and web services l TCP-C: on-line order entry environment l TCP-E: on-line transaction processing for brokerage firm l TPC-H: decision support — business oriented ad-hoc queries

4. File System & Web Benchmarks  SPEC System File System (SFS) l SPECFSF: a synthetic workload for NFS server, based on monitoring real systems l Results -Throughput (operations/sec) -Response time (average ms/operation)  SPEC Web Server benchmark l SPECWeb measures simultaneous user sessions, subject to required throughput/session l Three workloads: Banking, E-commerce, and Support

5. I/O vs. CPU Performance  Amdahl’s Law l Don’t neglect I/O performance as parallelism increases compute performance  Example l Benchmark takes 90s CPU time, 10s I/O time l Double the number of CPUs each 2 years -if I/O unchanged—it quickly becomes a bottleneck YearCPU timeI/O timeElapsed time% I/O time now90s10s100s10% +245s10s55s18% +423s10s33s31% +611s10s21s47% §6.9 Parallelism and I/O: RAID

6. RAID  Redundant Array of Inexpensive (Independent) Disks (see Fig 6.12) l Use multiple smaller disks (c.f. one large disk) l **Parallelism improves performance** l Plus extra disk(s) for redundant data storage  Provides fault tolerant storage system l Especially if failed disks can be “hot swapped”  RAID 0 l No redundancy (“AID”?) -Just stripe data over multiple disks l But it does improve performance

7. RAID 1 & 2  RAID 1: Mirroring l N + N disks, replicate data l Write data to both data disk and mirror disk l On disk failure, read from mirror l Widely used  RAID 2: Error correcting code (ECC) l N + E disks (e.g., 10 + 4) l Split data at bit level across N disks l Generate E-bit ECC l Too complex, not used in practice

8. RAID 3: Bit-Interleaved Parity  N + 1 disks l Data striped across N disks at byte level l Redundant disk stores parity bytes l Read access -Read all disks l Write access -Generate new parity and update all disks l On failure -Use parity to reconstruct missing data  Not widely used

9. RAID 4: Block-Interleaved Parity  N + 1 disks l Data striped across N disks at block level l Redundant disk stores parity for a group of blocks l Read access -Read only the disk holding the required block l Write access -Just read data disk containing modified block, and parity disk -Calculate new parity, update data disk and parity disk l On failure -Use parity to reconstruct missing data  Not widely used

10. RAID 3 vs RAID 4 for small writes All disks are accessed Only D0 & P are accessed

11. RAID 5: Distributed Parity  N + 1 disks l Like RAID 4, but parity blocks distributed across disks -Avoids parity disk being a bottleneck  Widely used

12. RAID 6: P + Q Redundancy  N + 2 disks l Like RAID 5, but two lots of parity l Greater fault tolerance, against multiple failures, through more redundancy  Multiple RAID l More advanced systems give similar fault tolerance with better performance

13. RAID Summary  RAID can improve performance and availability l High availability requires hot swapping  Assumes independent disk failures l Too bad if the building burns down!  RAID controllers often support multiple levels l E.g. RAID 0, RAID 1, RAID 5, and RAID 6  See “Hard Disk Performance, Quality and Reliability” l http://www.pcguide.com/ref/hdd/perf/index.htm

14. Fallacy: Disk Dependability  If a disk manufacturer quotes MTTF as 1,200,000hr (=140 years) l Believing that a disk will work that long: “Disks practically never fail”  Wrong! this is the mean time to failure l What is the distribution of failures? l What if you have 1000 disks -How many will fail per year? §6.12 Fallacies and Pitfalls See Figure 6.5 for some manufacturer-published AFRs

15. Fallacies  Disk failure rates are as specified in data sheet l Studies of average failure rates in the field -Schroeder and Gibson: 2% to 4% (vs. 0.6% to 0.8%) -Pinheiro, et al.: 1.7% (1st yr) to 8.6% (3rd yr) (vs. 1.5%) l Why?  A 1GB/s interconnect transfers 1GB in one sec l But what’s a GB? l For bandwidth, use 1GB = 10 9 B l For storage, use 1GB = 2 30 B = 1.075×10 9 B l So 1GB/sec is 0.93GB in one second -About 7% error

16. Pitfall: Offloading to I/O Processors  Overhead of managing (set up, etc) the I/O processor request may dominate l Quicker to do small operation on the CPU l But I/O architecture may prevent that  I/O processor may be slower than CPU l Since it’s supposed to be simpler, it is less powerful  Making it faster makes it into a major system component l Might need its own coprocessors!

17. Pitfall: Backing Up to Tape  Magnetic tape used to have advantages l Removable, high capacity  Advantages eroded by rapid disk technology developments  Makes better sense to replicate data l E.g, local RAID, remote mirroring

18. Pitfall: Peak Performance  Peak I/O rates are nearly impossible to achieve l Usually, some other system component limits performance l E.g., transfers to memory over a bus -Collision with DRAM refresh -Arbitration contention with other bus masters l E.g., 32-bit PCI bus: peak bandwidth ~133 MB/sec (4 bytes per transfer @33MHz bus clock rate) -In practice, only ~80MB/sec is sustainable -Actual performance on a bus depends on several factors (bus design, # of users, load, distance, etc)

19. Concluding Remarks  I/O performance measures l Throughput, response time l Dependability and cost also important  Buses used to connect CPU, memory, I/O controllers  Control and transfer via l Polling, interrupts, DMA controller, I/O processor(?)  I/O benchmarks l TPC, SPECSFS, SPECWeb  RAID l Improves performance and dependability §6.13 Concluding Remarks