Chapter 8

1. Chapter 8 Some parts adopted from Cornell university slides: http://www.csl.cornell.edu/courses/ece314/lecturenotes/l22_handouts_2up.pdf

2. Interfacing Processors and Peripherals • I/O Design affected by many factors (expandability, resilience, dependability) • Performance: • Measured by • access latency • throughput • Depends on • connection between devices and the system • the memory hierarchy • the operating system • A variety of different users (e.g., banks, supercomputers, engineers)

3. Which performance measure is important? • Depends on the application • Multimedia applications, most I/O requests are long streams, BW is important • File tax processing, lots of small I/O requests, need to handle large number of small I/O requests simultaneously • ATM transactions, both high throughput and short response time

4. Dependability, reliability and availability • Dependability: fuzzy concept • Needs reference specification • System alternating between two states: • Service accomplishment: service delivered as specified • Service interruption: delivered service is different from specified • Transition from 1 to 2  failure • Transition from 2 to 1 restoration

5. Dependability: quantified • Reliability: a measure of continuous service accomplishment, equivalently the time to failure from a reference point. • Reliability measured by MTTF (mean time to failure) • Service interruption is measured as mean time to repair (MTTR) • Mean time between failures (MTBF)

6. Dependability: quantified • Availability is a measure of service accomplishment wrt alternation between the two states of service • Increase availability by • Increase MTTF • Fault avoidance, fault tolerance, fault forecasting • Decrease MTTR • Tools for fault detection, diagnosis and repair

7. RAID: leveraging redundancy to improve reliability • RAID: redundant array of inexpensive disks • 7 levels: • Different redundancy amounts • Recovery from one versus two failures • RAID 0: • stripping data on several disks • No redundancy • Appears as one large disk • Useful for video applications, simultaneous access to different stripes

8. RAID: leveraging redundancy to improve reliability • RAID 1: • N + N disks, replicate data, Mirroring or shadowing (double number of disks) • When disk fails, go to mirror • Most expensive RAID • RAID 2: Error correcting code (ECC) • N + E disks (e.g., 10 + 4) • Split data at bit level across N disks • Generate E-bit ECC • Too complex, not used in practice

9. RAID 3: bit-interleaved parity • N + 1 disks • Data striped across N disks at byte level • Redundant disk stores parity • Read access • Read all disks • Write access • Generate new parity and update all disks • On failure • Use parity to reconstruct missing data • Not widely used

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

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

12. RAID summary • RAID can improve performance and availability • High availability requires hot swapping • Assumes independent disk failures • Too bad if the building burns down! • See “Hard Disk Performance, Quality and Reliability” • http://www.pcguide.com/ref/hdd/perf/index.htm

13. I/O Example: Buses • Shared communication link (one or more wires) • Data lines and control lines • Difficult design: — may be bottleneck — length of the bus — number of devices — support for many different devices — cost • Types of buses: — processor-memory (short high speed, custom design) — I/O (lengthy, different devices, e.g. USB, Firewire)

14. I/O Example: Buses • Synchronous • uses a clock and a synchronous protocol (actions happen on clock events) • Very fast and the interface logic is small • every device must operate at same rate • clock skew requires the bus to be short if it is fast • Processor-memory buses are usually synchronous as they are required to be fast and the length is small

15. I/O Example: Buses • Asynchronous • don’t use a clock • Can thus accommodate a wide range of devices • USB, Firewire are asynchronous • Handshaking protocol needs to be used to coordinate between sender and receiver • Handshaking protocol example (device requesting data word from the memory system) • ReadReq: indicates read request from memory • DataRdy: data requested is ready • Ack: other party (e.g. device) acknowledges the receipt of data (or end of sending), only then ReadReq and DataRdyare de-asserted

16. Key characteristics of two dominant I/O bus standards

17. Typical x86 PC I/O System

18. Interfacing I/O devices to the processor, memory and operating system • How to give commands to I/O devices? (read/write/…) • How the actual data transfer happens? • What is the role of the OS?

19. Interfacing I/O devices to processor, memory and OS • OS plays major role acting as the interface between the hardware and the program that requests I/O • OS responsibilities arise from the following • Multiple programs using the processor share I/O system. OS schedules access to I/O to maximize performance • I/O system uses interrupts (externally generated exceptions). Interrupts cause transfer to kernel (supervised) mode  must be handled by OS • Low-level of device handling is complex (e.g. managing concurrent events) , OS provides routines for that

20. Kernel mode • Kernel mode, also referred to as system mode, is one of the two distinct modes of operation of the CPU (central processing unit). • The other is user mode, a non-privileged mode for user programs, that is, for everything other than the kernel. • When the CPU is in kernel mode, it is assumed to be executing trusted software, and thus it can execute any instructions and reference any memory addresses. • The kernel (which is the core of the OS and has complete control over everything that occurs in the system) is trusted software, but all other programs are considered untrusted software. • Thus, all user mode software must request use of the kernel by means of a system call in order to perform privileged instructions, such as process creation or input/output operations.

21. OS role • The above three c/ch require OS provide • OS guarantees user program accesses portions of I/O to which it has rights (protection). If program can directly talk to I/O, this protection cannot be enforced • OS provides abstractions that help program accessing devices while shielding away details • OS handles interrupts generated by I/O devices the same as exceptions generated by programs • OS tries to provide equitable access to shared resources as well as e enhance system throughput • To provide these functionalities, OS must be able to communicate with I/O devices and prevent programs from directly talking to the devices

22. Communication types between OS and devices • Give commands to I/O devices such as read, write, … as well as others such as disk seek • Device should notify OS when operation completed such as disk seek • Actual data transfer between device and memory