Chapter 5 Notes

3 Chapter 5 Input Output Device Manager Important is one of those funny words you come across all the time in this industry. You should be asking questions like important to whom or important for what. Knowing what you are doing will drive what is and what is not important. Getting back to this survey. Most common output device would be some type of video display. Most computers are geared to a visual environment so having a video display is common. For input the most common would be some type of text entry device, such as a keyboard. Though a pointing device is up there as well. This part of an Operating System (see Figure 1) is usually either ignored or given only cursory coverage in most Operating System text books. And the reason is clear, in the past most of the software and all of the hardware was considered outside the Operating System. Only a few configuration files were managed by the Operating System. And in the early days of desktop systems (1980s) most of the problems with the computer system came down to input or output issues. These included conflicting interrupts, drivers loaded in the wrong location, improper memory space allocation for the device, and—the big one—an updated driver that doesn’t work with some device. This is where Information Technology professionals spent their time. And many of these were intermittent issues so tracking them down took loads of time. Today the systems have more stability, and we are working with a different construct for organization (I will get to that in this chapter), but the issue of input and output did not disappear from our work. Figure 1 The Input Output Device Manager Alt Tag. Operating System Notational Diagram highlighting the Input Output Device Manager and Input Output hardware. In this chapter I will discuss how input and output operates and how it is managed by the Operating System. I will go into detail about the mechanisms used and the storage structures set up to make all these parts function together. As in other chapters some of this is specific to what

Chapter 5 Input Output Device Manager 6 Table 1 Input Devices 10-key device Joystick Punched Card Reader 3D Scanner Keyboard Pyrometer Barcode Ready Kinect Sensor Scanner Camera Media Player Tachometer Digital Pen Microphone Touch pad Gamepad Mouse Touch screen Humidistat Paddle Trackball Jog Dial Pointing Stick Tracker Thought Question: List all the computer output devices you can think of? Table 2 shows a brief list of output devices. Table 2 Output Devices Actuator 3 Printer Speakers Monitor Punched Cards Thought Question: List all the computer devices missing from your input and output list? 3 This one is lumped and anything that does something is an actuator. Thus, anti-lock brakes and a machine shop lathe are both considered actuators.

9 Chapter 5 Input Output Device Manager Figure 3 Text Entry Block Diagram Alt Tag: Block diagram of text entry example showing the keyboard, encoding, communication to the computer and communication, decoding, and display Bear in mind, this is grossly oversimplified. Allow me to focus on the keyboard data rate. While the average typing speed is around 45 words per minute (wpm), the fastest typist comes in at 216 wpm 5 . A word is considered 5 letters plus a space, so this translates to 270 characters per minute (cpm) for the average and 1296 cpm for the absolute fastest seen to date. Converting to seconds this is 4.5 characters per second (cps) on average and 21.6 cps maximum. If we are using ASCII with a parity bit (for a total of 8 bits) that takes the data rate to 36 bits per second (bps) for the average typist and 172.8 bps for the absolute fastest. This is at the low end. Gigabit Ethernet is at or near the high end with 1 Gbps. Table 4 shows a list of ranges in data rates and shows an overall range of 36 bps to 5 Gbps—that is 8 orders for magnitude that must be accommodated by the system! I have provided other examples in the sidebar. Table 4 Typical Input and Output Data Transfer Rates Device Type Data Rate Keyboard Input 0 to 172.8 bps (36 bps average) Mouse Input 110 bps Modem Input / Output 0.1 to 56 Kbps 6 Floppy Disk Drive Input / Output 1 Mbps Printer Output 1 Mbps Laser Printer Output 2 Mbps 5 Set by Stella Pajunas in 1946 on an IBM electric typewriter 6 110 baud modems were introduced in 1958 using Frequency Shift Key (FSK) of 2 values and the technology increased frequently until in the late 1990s when 8000 baud or 56kbps modems were available using digital modulation techniques. Baud refers to the number of symbols transmitted each second. In the early modems the symbols only represented 2 values (0 and 1). Later different encoding or modulation techniques were used to increase the signal content in each symbol. So, in the 56k modems the symbols represented 7 values each.

Chapter 5 Input Output Device Manager 12 drive or random as in a hard drive. I believe another category has emerged here and I call it direct as in a Solid-State Drive (SSD). This may be a little confusing, especially since in Chapter 2 we discussed Random Access Memory (RAM) and it has the same structure as an SSD. My view is with an SSD (and RAM) the system directly addresses the location. A hard drive must move mechanical parts to get to that location and that takes additional time. In addition, as you obtain data from a hard drive these mechanical parts must be reposition as you collect the full set of data. So, I think the separation is justified. Second is the ability to share the device. A printer must be dedicated or the output you get doesn’t make much sense, but a disk drive can be shared across many applications and still work correctly. Dedicated simply means that the input or output device can be assigned to one job at a time. Shareable means multiple jobs can be assigned. Virtual is a third way to look at this dimension and has become increasingly important with our systems. These are devices which don’t physically exist but are assigned to jobs then abstraction is used to associate them with a physical device. Third is I/O direction. Devices and be read only as in a CD-ROM (meaning an input device only). They may also be write only as in a monitor. Or a device and be read-write as in a disk drive. The characterization is becoming cloudy here as many devices are being designed that have some ability to transfer data the other way. For example, modern monitors can send data to the CPU to give its characteristics. Fourth, the specific function of the input or output of the device matters. It would be a pointing device, an entry device, a display, or something else. Finally, each device has its unique set of error conditions due to the nature of what the device is and how it is constructed. For example, you will never get a jammed paper error from a monitor or hard drive. This error condition is “unique” to printers. Yes, I quoted unique there because other devices (like a scanner) may also have that condition. The very nature of errors that can occur on a device, how they are reported, and what recovery actions the Operating System may take depends on the very specific device. Meaning error codes from Hewlett-Packard do not have to be the same as those from Epson. There are many other differences in input and output devices. These include the time it takes for the device to respond (latency), how long it takes to locate the data (seek time), and how often a request can be made of the device (recovery time). Many do not affect how the Operating System would operate the device but they do affect performance. Table 5 shows some specific characteristics of a couple devices. Some of these may also be considered performance measures for the device. Table 5 Specific Characteristics of Some Input and Output Devices Characteristic Device Example Luminance Monitor Projector Aspect Ratio Monitor Projector 6:9 Image Size Monitor Projector 14.1 inches Resolution Monitor Projector 1680 x 2460

15 Chapter 5 Input Output Device Manager system. I also showed that these systems are much slower than the rest of the computer system as well. Each year we see new entrants into this market with new devices adding more variety. The industry continues to take steps to help reduce the burden on the CPU and the Operating System through hardware and software standards. It is these two areas that Operating Systems can provide the greatest benefit. Thus, the two objectives for the Operating System in input and output are improved abstractions and efficiency. The objective of improved abstractions will allow the applications and users a common interface to all the devices. This allows the Operating System to handle all devices in a uniform manner. You can think of this one as device independence, meaning the operating system and programs go to generic input or output without regard for the particular device then the core Operating System through the manufacturer provided device drives handles the specific details of the device. It is unlikely we will ever achieve this objective fully since the shear diversity of devices hinders us. If we approach the problem logically, we could set up a system that uses some of the concepts of Object Oriented Programming such as inheritance to set up a device hierarchy to group similar devices. In current windows system the Windows Registry uses this approach for the configuration settings. It is both hierarchical and modular. Approaches such as these allow the Operating System to manage input and output in a more general manner, treating as many types of systems with the same sets of commands and management structures. It also allows programs to be written in a general manner taking hold of the abstraction and not worrying about the details. The abstraction also flows over to other areas and is usually addressed in the standards. Two of these areas are with uniform naming and uniform errors. Keeping these two areas uniform helps manage the hierarchy and helps with the handling of problems that come up with the devices. While improved abstractions help with the trends in Input and Output, it does not help growing performance difference between the CPU and the input or output devices. Hence the need for the second objective--efficiency. The Input and Output devices are usually the bottleneck for the computer because they are slow compared to the CPU. And pretty much nothing can be done without going to the disk and other input devices. Companies spend a good portion of their development budget to make the devices more efficient to address the bottleneck but like memory they continue to fall behind the CPU processing speed. I will go into more detail about disk drives in Chapter 6 but let me say here that it is the disk input and output that receives the greatest attention. For the overall system, multiprogramming helps keep the CPU busy as the CPU makes progress on other tasks, while a task is waiting for input or output. 5.1.4 Operating System Involvement Now that we know what input and output is, why we have them, and some of the issues and goals are, let me turn to what the Operating System does. We have learned that an Operating System controls everything a computer does. So naturally an Operating System will control all the computers input and output. The Operating System will issue commands, catch completions, and handle any errors that come up with the goal of ensuring the system does not get caught off Trends in Input and Output 1. Rate of entry for new devices being placed on the market is increasing. 2. More stringent standards for Software and Hardware interfaces continue to be applied.

Chapter 5 Input Output Device Manager 18 a. Efficiency b. Standardization c. Generality d. Variability e. Reliability f. Improved Abstraction 4. What objectives do the Input Output Device Manager try to achieve? a. Efficiency b. Standardization c. Generality d. Variability] e. Reliability f. Improved Abstraction

21 Chapter 5 Input Output Device Manager  A single CPU  Four DDR4 modules  Four Direct USB 3.0 channels  One Direct USB 3.0 channel with C-connector  Two USB 2.0 extensions (with 2 ports each)  Two USB 3.0 extensions (with 2 ports each)  Six SATA Connectors  One Comm extension (for serial ports)  One RG-45 LAN connector  One DVI connector  One HDMI connector  One PS-2 connector  Two input audio channels (line in and microphone)  Four output audio channels  Panel Audio extension  An M2 socket for either Wi-Fi or SSD  Three PCIE graphics slots Sadly, not all of these can be used at one time, and it is up to the Information Technologist assembling a system with this (or any) board to make good choices on hardware placement then setting up the software and BIOS. Note that the majority of input and output buses here are the serial busses (USB, SATA, PS-2 LAN, and Comm extension) while the others (PCI, DVI, and HDMI) can operate serially or in parallel. Only the memory cards operate strictly in parallel.

Chapter 5 Input Output Device Manager 22 Figure 5 Motherboard with busses labeled Alt Tag: The ASRock Z270 Extreme Motherboard, labeled with busses present Check Your Understanding 1. What are two general categories of input and output? a. Communications port b. Human readable c. Read only devices d. Machine readable 2. What is a passive device? a. One that does not require power b. One that sits idle most of the time c. One that is under the direct control of the CPU d. One that operates independent of the CPU

23 Chapter 5 Input Output Device Manager Section 5.3 Operating System Organization At this point I have probably done a really good job at convincing you of the near impossibility of the Operating Systems job. Let us examine what the Input Output Device Manager of the Operating System must do to make all the input and output work. 5.3.1 Architecture First the Device Manager must identify all the devices connected to the computer system and set up structures to manage the device. The Operating System sets up structures, which I will discuss in the next section. These structures will connect the Operating System code and device driver code to each specific device. A master list is created during the boot up process where the Operating System sends test signals down all the bus lines requesting all devices to identify themselves. As new devices are added to the system, they are added to this master list. The Operating System must track the status of each device and know which ones are available and where the others are at in their current operation. It uses preset policies to determine which tasks will get a device and for how long the task can hold the device. The Device Manager will decide which devices get allocated to which tasks and when they should be deallocated from the task. The deallocation may occur at the task level once the input or output command has been completed (a temporary situation) then to permanently deallocate the device once the entire set of commands for a specific task is fully completed. If an error condition occurs the Device Manager takes the error code and determines how to handle the situation. Finally, the Device Manager is responsible for providing the standard interface between the CPU and the input or output device. We learned in Chapter 4 the Operating System restricts to the Kernel commands that are going to direct hardware functions so the Kernel is involved with the direction. Most Operating Systems have a special subsystem in the kernel to do this—the Kernel I/O subsystem. Now the Operating System does not interface directly with the input or output device. The actual device after all is an electro-mechanical device and the device manufacturer has provided it with a device controller that directly controls the device. This controller may be solely in the device, or partially in the device and partially in a card. It may also be the case that the device controller is standardized so that many devices use the same device controller. Whatever the case, the device manufacturer also provides a device driver , which is software that is written specifically with this device’s characteristics. The Operating System interfaces through this driver to control through the device controller, the input or output device. Device drivers actually become part of the Operating System. In most systems today they become part of the Kernel though in the past they have been in the user space, and it is still possible to find them there. In mainframes, they are compiled directly into the binary. This is feasible since the systems are generally sable over time. In Personal Computers this cannot be the case and the drivers are many times dynamically loaded during execution. What I have just described is a layered architecture approach to this problem on the low-level side. On the other side, the Operating System interfaces with the application presenting a logical input and output system to the application. I show this graphically in Figure 6. So, the application program deals with a logical input or output device and is not concerned with the details of controlling the device. At this point the Operating System is concerned with managing a generic input and output function. The Input Output Device Manager takes the requested operations and data and converts them into an appropriate sequence of input or output instructions using the proper orders from the device drivers and ports and channels from the data structures set up by the Operating System when the device was recognized. The Input Output

Chapter 5 Input Output Device Manager 24 Device Manager also takes care of putting the requests in a queue according to an appropriate scheduling algorithm to ensure maximum performance of the input or output device. The device is monitored, errors handled, and status is collected and reported. Differing input or output systems may need more than this as a system of files would need a structure that is human readable to locate information. Figure 6 Input and Output Layered Approach Alt Tag: Input and Output Layered Approach showing the application, the logical input and output in the Operating System, the device input and output in the Kernel, the device driver, the device controller, and the input or output device Let us step back and think about this for a second. The Operating System restricts the interface to the Kernel to protect the system, but the communication is to run the driver, a piece of software written by some third party. Yes. It is one of those situations where the Operating System must trust the third-party code because it is in these device drivers that the full set of device functionality exists. The Operating System wants to make the interface to the application device independent, but each manufacturer is free to take advantage of hardware and software details they have designed to make their device “better” than everyone else’s device. Do we put the computer system at risk here? No. The Operating System ensures the driver is only used on its intended device so if a flaw exists the damage will be limited to the device with the overall system only suffering from at most a reboot. When an input or output device is recognized by the Operating System, the device driver assists the Operating System by filling in some of the blanks it needs to manage and control the device. This allows the Operating System to set up the data structures it needs and sets up unique identification numbers (handles in Windows) to set it apart from all other devices. If the device is a block-oriented device, the block size is defined. If the device is a stream oriented device, then the stream is defined. The Operating also identifies the port, the interrupt, the location of the code for each situation, and the acceptable commands to be used. These all define the handshaking protocol for the Operating System to direct and control the input or output device.

25 Chapter 5 Input Output Device Manager This allows the Operating system to issue commands, handle errors, and pass data between the application and the device. Let us work through an example of an input instruction. The application program makes a request for data from a specific device. It provides what it needs and how much it needs. The Operating System acknowledges the request. If the request is a blocking call the current task is blocked, and execution of tasks is moved to the next one. then determines where to put the data (it knows what memory is owned by the application) and breaks the request into a series of commands taking into account the type of transfer (block or stream) and size. The Operating System also knows the status of the input and output device and works this request into the schedule for the device. Prior to issue any commands to the device, the Operating System ensures memory is available and allocated to store this data and the Memory Management system protects this block from other uses. Once the Operating System issues the commands to the device, the Operating System monitors its status until complete. Once all the commands have completed, the Operating System notifies the application that its data is ready for use. If the task was blocked from a blocking call, then the task put in the queue for execution. Bear in mind that this is bare –bones and there are other parts of the system that could come into the mix here. I have left them out here and will bring them in as performance enhances later in this chapter. 5.3.2 Support Structures Let me see if I can help bring some order to all of that. Let me start with some review of Chapter 3. There we learned about registers in the microprocessor. There was an I/O Address Register and an I/O Buffer Register. The I/O Address Register designates where the I/O is, and the I/O Buffer Register holds incoming or outgoing data for the CPU. Many times, the I/O Buffer will hold the instructions we want the input or output device to do. It is sent to the address in the I/O Address Register. So, all the commands we talk about boil down to sending a short stream of data to the Input or Output device. Well CPUs are really quite stupid so we would need something that simple. On the device end (which may be the device controller) we have something similar. A few registers for accepting a short stream of bits. This stream is the command. Now in the real earlier days there were lots of commands since the CPU was directly directing what the device was doing. And the CPU had in its instruction repertoire al the commands necessary for this. Nowadays it is simpler because the device or its controller interpret what the CPU sent and do all the execution until it encounters a problem (an error) or is finished (a completion code). Thus, simply by writing something into these registers, the Operating System can command the device to deliver data, accept data, turn on or off, or do something entirely different. And by reading these registers, the Operating System can learn the state of the device. And the device or the computer or both may have a data buffer to accept the data, but I will hold off on this story until later in this chapter. There may also be a whole slew of control registers for this purpose with each one assigned to an input or output port. This series of registers would be called the I/O port space. The registers are protected and take special instructions to access (like In or Out). Early mainframes like the IBM 360 series worked in this manner. Sometimes this is designed differently. (I know what a surprise!) Instead of the CPU having special registers for input or output, we may have some space designated in memory for input and output. This is called Memory Mapped Input Output. Thus, memory is separated into

Chapter 5 Input Output Device Manager 26 memory address space and I/O address space. While the two address spaces are different and there is a signal line to designate which one is called upon, the addresses are normally not duplicated. In some machines both exist, and the registers are simply mapped to the memory space, usually at the top of memory. This was introduced in DEC’s PDP-11 line. Some systems do both like the Pentium. Addresses from 640k to 1M are considered memory mapped I/O. Advantages of memory mapped I/O include not needing any special I/O commands—a move to a memory location is all that is needed. So, any instruction that can access memory, can now access the I/O control registers. And since memory is inherently protected (we will see this later) no special mechanisms are needed for I/O protection. But there is also a cost. While cache has worked wonders for the memory hierarchy, it can be disastrous for input and output. Changes made by the device will not be seen by the CPU unless the cache can be selectively disabled, and of course the CPU must monitor the memory locations to detect the change. These techniques get the commands and status to and from the Input or Output Device. Other structures are needed to keep track of the Input and Output. Many Operating System Subsystems have similar tables that keep track of the resources (input and output devices here) and who owns them. Much of the information is temporarily duplicated in the task areas for easy reference. These are in the form of table which is proprietary to the Operating System. They could contain.  Unique Identifier  Current Owner  Location of Device Driver  Location of Control Register  Location of Status Register  Starting Location of Error Vectors  Channel or port  Status The Unique Identifier is an integer that can be used by programs to call this device. The Current Owner is the application that is currently using the device. In shareable devices this would be a pointer to a table that has a list of owners and the remaining availability of the device. This table would also contain the control and status register for this application—device duplet. Location of Device Driver is the start of the code for the device. When first called this is the address to get the code to execute. Control and Status Register are the communication tools between the CPU and the Input or Output Device or Device Controller. They are either registers or memory locations. Channel is the physical bus location of the device. The Error Vectors contain the code to execute in the event of each error condition. The code is contained within the Device Driver. The Status contains the current status of the input or output device. Some Operating Systems, such as Windows, have implemented more complex configuration files. In Windows this is the registry, and the registry contains additional settings for general and specific input and output configurations.

27 Chapter 5 Input Output Device Manager 5.3.3 System Calls System Calls for input and output are kept generic so they can be applied to many different devices. Here are some of the most common. Open a file for reading, writing, or both. Rather than focused on a device this one is focused on a specific file from a device. I will cover the file operations in greater detail in a later chapter. Close a file reverses what Open did. Write data to a file. Read data from a file Stat gets information about a file Lseek repositions the pointer in the file. ReadConsole and WriteConsole are the same a read and write except it deals with the console input or output buffer. In UNIX and Linux these work for general Input or Output as all devices are viewed as files. Then there are commands to:  Request a device  Release a device  Get and set attributes  Logically attach or detach devices Check Your Understanding 1. What is the basic architecture used by the Operating System for input and output? a. Kernel b. Layered c. Microkernel d. Object Oriented e. Hierarchical

Chapter 5 Input Output Device Manager 28 2. In its most basic form, how is an I/O device given direction? a. Activating the correct control line out of the CPU b. Applying power to the device c. Sending a control word from the CPU to the device or device controller 3. Why must the Operating System keep track of all Input and Output Devices? a. To manage and control the devices b. To ensure all memory is used c. To separate input and output memory from file memory d. To ensure only Input or Output Devices get special I/O instructions

29 Chapter 5 Input Output Device Manager Section 5.4 Communicating with Input and Output At this point our view of Input and Output is some control mechanisms and some method to pass information back and forth. With Memory Mapped I/O this is two way into memory but the CPU is responsible for checking memory to get status of the I/O Device. The I/O Device must also check memory to check if it has something to do. With an IO space the CPU just sends information to the IO Device. I have skirted around the issue of how the Input or Output Device gets information the other way. This is only part of the story. Most textbooks will tell you that there are three techniques for performing Input and Output – Programmed I/O (also known as Polling), Interrupt-drive I/O, and Direct Memory Access (DMA). With Programmed I/O the processor issues and I/O command on behalf of a task to an I/O Device, then the task waits for the operation to be completed before proceeding. With Interrupt-drive I/O the processor issues an I/O command on behalf of a task then for a non- blocking call the processor continues to execute instructions for the task that issued the I/O command. For blocking calls, the Operating System blocks the task and moves onto the next task. In either case when the I/O operation is completed it issues an interrupt to CPU that reports its completion of the operation. The task is notified or unblocked. With DMA, a DMA module controls the exchange of data between main memory and an I/O module. Whoa! Hang on a minute. What does that have to do with issuing the instruction? Nothing at all. With I/O the Operating System must separate the actions into two stages. The I/O request and the data transfer. For Input the data transfer occurs after the request for output it occurs either before or after the request depending on how it is completed. Let me take input and output separately here. For input the Operating System issues the command for input. In the command it may set up memory space for the data. The IO Device goes about its business. When complete it will update its status register that it has completed. If using memory mapped IO, the register in memory is also updated. If using DMA, the data has already been placed into the memory space set up for it. So, the data either remains in the device or its controller or is in memory at the location specified. If the IO technique in use is Programmed IO, then the Operating System has been periodically checking on completion. This could have kept the Operating System tied up during this time doing nothing else or the Operating System could have a method to have it check periodically allowing it to do other tasks in the interim. If the IO technique in use is Interrupt- driven then the IO device will issue an interrupt when it has completed, letting the CPU and the Operating System know data is ready. Getting the data could be by Programmed I/O where the Operating System directly controls the transfer of the data from the device to the desired location. It could also be by interrupt where a command is issued for the data to be put someplace (either in memory) or an IO device register, then when the data is there the device issues an interrupt. The CPU runs a short routine to capture the data and put it in the new location. The final method is DMA. In this case the DMA has already placed the data in the proper memory location and nothing more needs to be done. For output the Operating System can either put the data to be moved in a memory location prior to invoking IO or have it in another location. The command sequence is the same as for input except for the order of data handling. For the transfer the Operating System can use Programmed IO where the command is given then followed with data when the IO device needs it. The data is sent directly to the IO Device (through the Device Controller). With Interrupt Driven after the data is sent the Operating System waits until notified by an interrupt that more data is needed.

Chapter 5 Input Output Device Manager 30 With DMA the data is already in memory and the command directs the DMA and IO Device to use it. When the operation is fully complete either an interrupt is given, or the Operating System checks the status word. Generally, if DMA is used, then the IO technique is almost always interrupt driven. Let us now examine how the processor uses these techniques to work with I/O. 5.4.1 Polling With polling the entire sequence is written in instructions (ergo Programmed I/O). When the processor needs some I/O completed it sends a command to the I/O device. The processor then waits (busy waits) until the I/O device is complete or is ready to provide partial data streams. During this time, the I/O device is working the command. Periodically the processor requests if the I/O is complete. Once it is complete the I/O device acknowledges the processor and the two coordinate a transfer of the data. During this time, the processor is only servicing the I/O device and nothing else is being done. Most times this is viewed as a wasteful use of the processor. There may be applications where this is acceptable or even desired. For the keyboard example, the initial command to the keyboard would be to set it up for input by defining the keyboard layout (English QWERTY for example) then periodically checking for input from the keyboard. Whenever a key is pressed the processor would accept the character, process it then return to the busy loop waiting for another. As I type these words this would be acceptable because the processing would be to store the character into the word processor database, check that spelling and grammar remain correct, and then display it. The processor would then return to its busy waiting cycle for the next character. 5.4.2 Interrupts With interrupts , the processor would issue a command to the I/O device, the I/O device would acknowledge the command, the both the processor and I/O device would go off do their tasks – the processor off doing something perhaps unrelated, the I/O device processing the command. When the I/O device is complete or partially complete (needing to transfer data so it can continue), it issues an interrupt service request to the processor. The processor switches context to the interrupt handler. The processor executes the service request by transferring data then resumes its former processing. This allows the processor to complete other tasks while still handling I/O making it more efficient than programmed I/O. It still requires active intervention of the processor to transfer the data between memory and the I/O module. Using the keyboard example, as before the processor would issue the initial command to the keyboard to set it up for input by defining the keyboard layout (English QWERTY for example). The processor would then move to other tasks. The keyboard would wait for input and when a key is pressed would issue an interrupt for service. The processor would switch tasks (context switch) and transfer the character to memory. The processor would return to the tasks it was doing. At some point the processor would return to working on word processor data base to check the spelling and grammar and display the result to the screen. There are three drawbacks to using interrupts. First the transfer rate is limited by the speed with which the processor can test and service the device. Second, the processor is tied up in directly managing an I/O transfer because to do this several instructions must be executed for each I/O transfer. And third the processor is limited in the number of bytes transfers it can do. If our context switch takes 40 nanoseconds and it takes 10 nanoseconds to transfer a byte, then another 40 nanoseconds to switch back to the program. That is 90 nanoseconds per byte. This would limit data transfers to 10 MB/second. This is fine for slow devices such as the keyboard, but it

31 Chapter 5 Input Output Device Manager would dramatically limit a hard disk that is designed for transfer rates of 25 MB/sec. This disk would have a new byte ready every 40 nanoseconds. The fast processor would limit data transfers from this I/O device. Our bottleneck is the context switch and processor intervention with every single byte. We could speed this up by buffering the data at the I/O device and transferring a block of data rather than a byte. Sometimes this is done but there is a more eloquent solution to this dilemma. There are other issues with Interrupts. First, they may have priorities meaning some are more important than others. So, if what the Input Output system needs is less important than what is happening, it will be put on hold until the more important task is completed. Second is the CPU must identify the proper subroutine to run. This is called the interrupt handler and is usually found through an interrupt vector. The vector specifies the address for the instruction. Third the interrupt can be blocked or disabled if some program is in a critical section of code. A critical section of code is code that cannot be interrupted. To remedy this uses the CPU can have Multiple Interrupt Request Lines which are aligned with the priories. In this way the CPU does not have to stop a high priory task just to check whether another interrupt will supersede it. The system could also group devices along the same interrupt line. This is called chaining and is used when a system has a large number of devices. If this is done the service routine must have some method to identify which device posted the interrupt. 5.4.3 Direct Memory Access We can give the I/O controller access to memory by using a device with Direct Memory Access (DMA). This is significant enough, that some authors classify DMA as a third method of handling I/O. I prefer to put DMA as a subset to the interrupt methodology. The DMA is simply a smart device that is capable of directly interacting with the bus (become the bus master). Instead of sending commands directly to the I/O device, the processor sends the command to the DMA. In the command the processor identifies the device, whether a read or a write is requested, the start location of the data, the number of words to be read/written, and the memory location the data is coming from (for a write) or going to (for a read). The DMA interfaces with the I/O device. The DMA spends the time waiting for the I/O device to be ready then sets it up for the task and periodically moves the data to or from memory. When the task is complete the DMA issues an interrupt to the processor informing it that the task is complete. At this point there is no data transfer because the data is already in memory. The entire transfer of data to/from the I/O device and memory is performed by the DMA. The processor is only involved at the beginning to issue the command and at the end of the transfer to acknowledge its completion. The processor does execute more slowly during the I/O because access to the memory bus is being shared with the DMA, but it is performing other tasks making it more efficient than both interrupts and polling (don’t use programmed I/O for this as we are doing to use it for the below). Sharing the bus is possible because transfers between the DMA and memory are generally small. The hardware in a DMA is similar to that inside any other Device Controller. There is an address register that holds the beginning location in memory, a Data Count register that holds the size of memory, and a Data register that the data will flow through to or from memory. There is also control logic that provides for the requested operation and the direction of transfer (read or write). The DMA also has an interrupt line to the CPU and a line to acknowledge the operation.

Chapter 5 Input Output Device Manager 32 The DMA may very well be part of the Device Controller, included in the bus architecture, or be a separate device between the I/O and the CPU. The DMA configuration is system dependent but in general may be placed in one of three different configurations as shown in Figure 7. The first configuration, the single bus is used in the most simplest of systems because the Input and Output device shares the bus with the DMA, memory, and the CPU. Being much slower than the CPU, the Input Output Device Controller will take up a significant percentage of the bus time. And then the DMA must take that data and move it to memory taking additional time from the CPU. The second configuration also uses a single bus, but no Input or Output device has direct access to the bus. The DMA moves the data between itself, and the IO Device then completes a burst to memory. The final configuration operates similarly but instead of dedicated DMA to specific IO Devices, any IO Device on the bus shares the DMA. If you examine these last two closely you will see it resembles the current bus structures systems have today. Figure 7 DMA Configurations Alt Tag: The three DMA configurations: single shared bus, single bus with integrated DMA, dedicated I/O bus 5.4.4 Putting it together In general purpose computers the I/O devices usually do not issue the command directly to the processor. Instead, they work through an Interrupt controller that accepts the interrupt and manages them. The controller issues commands on behalf of the device, taking into consideration the priority of the device. It then identifies the interrupting device to the processor. There are also special commands for the processor to disable or mask interrupts if the processor

33 Chapter 5 Input Output Device Manager or programmer desires. The interrupt controller can also remap priority levels if the default levels are not optimal for the implementation. There are classes of interrupts.  A Program interrupt is generated by some condition that occurs as a result of an instruction execution, such as arithmetic overflow, division by zero, attempt to execute an illegal machine instruction, or reference outside a user’s allowed memory space. These are generally referred to as traps)  A Timer interrupt is generated by a time within the processor. This allows the operating system to perform certain functions on a regular basis.  An Input/Output interrupt is generated by an Input/Output controller, to signal normal completion of an operation or to signal a variety of error conditions.  A Hardware Failure interrupt is generated by a failure of hardware, such as power failure or memory parity error (again trap). There are two techniques for the processor to interface with I/O devices, memory mapped I/O and Programmed I/O. In memory mapped I/O device communication goes over the memory bus. Commands are placed in special locations in memory. The device with specialize hardware or DMA periodically checks its location for commands, when found it executes the commands and updates the status word in memory when complete. The processor monitors this status word. With memory mapped I/O each device appears as if it is part of the memory address space. With programmed I/O the processor has dedicated, special instructions for I/O. Additionally, the processor has additional input/out wires (and I/O bus). The instruction specifies the device and the operation. Today memory mapped I/O is the predominate device interfacing techniques in use. Check Your Understanding. 1. What are the two methods for performing Input and Output operations on today’s computers? (Select all that apply) a. DMA b. Programmed Input output c. System Calls d. Interrupt Driven Input output

Chapter 5 Input Output Device Manager 34 e. Memory Mapped I/O f. I/O Space 2. What are the three methods for transferring data between the CPU and Input Output Device? a. DMA b. Programmed Input Output c. System Calls d. Interrupt Driven Input Output e. Memory Mapped I/O f. I/O Space

35 Chapter 5 Input Output Device Manager Section 5.5 Technology to Improve Input and Output Input and Output is slow compared to the rest of the system and in many cases, it cannot be made faster because the input or output involves interacting with the real world—many times with humans themselves. But the name of the game is to keep the CPU busy and there are improvements that can be added to the system to help with that. I will cover three of these here, buffering, disk cache, and memory mapping. 5.5.1 Buffering A buffer is a region of physical memory that is used to temporarily store data while it is being moved from one location to another. It can be used between any two objects but is used frequently in the input and output world. The data is sent to the buffer by a producer and is removed from the buffer by a consumer. A hard fast rule for buffer operation is the average rate of removal must be absolutely less than the average rate of insertion. I will show later in this section what exactly that means. Here are several uses of a buffer. 1. During an input transfer, the input device transfers data into the buffer. When complete the task moves the block of data in the buffer to its user space then requests more data for the buffer. 2. During stream transfers, the buffer can hold a line of data that is transferred when a carriage return is detected. 3. Buffer can be used to bring in data to memory in advance of its request or to hold data for output until well after the request has been made. 4. Buffering allows for differing rates of production and consumption and smoothes out peaks in input or output production. Buffering decouples the producer from the consumer so they can both work in their own time scale and is just a simple first-in, first-out (FIFO) queue meaning the order of accessing the data is unchanged through the buffer. Implementation is just a sequential series of memory locations and one or more pointers to keep track of where the producer and consumer are. When conducting IO without a buffer, the Operating System simply accesses the IO Device when servicing is needed and transfers the data directly to the task. With a buffer the situation is changed slightly (see Figure 8). Here the producer places the data in the buffer while the consumer removes the data from the buffer. A FIFO buffer can be accessed by both devices and the Operating System must ensure that the producer does not overwrite data until used by the consumer (recall the average consumption must be at least as great as the average production) and the consumer does not try to use data before it is store A simpler method to accomplish this is for only the producer or the consumer to access the buffer, but not both at the same time. When the producer fills the buffer, it is turned over to the consumer. This assumes that the producer puts production on hold while the consumer is using the data the consumer cannot get any new data until the producer has finished.

Chapter 5 Input Output Device Manager 36 Figure 8 Single Buffer Alt Tag: Operation of a single buffer To get around this problem, the Operating System can set up a double buffer. Here the producer transfers data to one buffer while the consumer transfers data from the other buffer. Here the Operating System just ensures the Producer and Consumer do not get past the buffer size and switches buffers when necessary to ensure the data flow is maintained. (See Figure 9.) Figure 9 Double Buffer Alt Tag: Operation of a double buffer Sidebar A while back I worked as an Air Traffic Control technician. The long-range radar system we used was a very old system that had a range of 300 miles (nautical miles since we are talking aviation here). If you went to Moving Target Indicator (MTI) mode, the range was 100 miles. In that mode the Pulse Repetition Frequency (PRF)—meaning the number of times the radar transmitted per second--was 800 so the interval between pulses was 1250 µsec (1/800). A radar mile (the time it takes Rf energy to travel 1 mile and back) is 12.35 µsec which is why you get the 100 miles here. This raw radar video on the display is called primary radar and is an actual return. But given it is an Air Traffic Control system, you wanted other (digital—though not what we would consider digital today) data put on the screen as well such as aircraft identification numbers, Identification Friend or Foe (IFF) information, altitude, etc. But it takes time to draw this information on the screen and if you are displaying live radar, you do not have any because the screen is displaying live radar and it takes 1250 µsec to display, well, 1250 µsec of live radar data. The other information is considered secondary radar data and back then you could not control aircraft with it. So, a way was needed to display both. Enter double buffering. During the live sweep the live radar information was digitized into 4 bits (that’s sixteen amplitude levels—enough to tell the difference on a screen) and clocked into the buffer at live speeds. On the next pulse, the information was clocked out

37 Chapter 5 Input Output Device Manager of the buffer at eight times live speed which takes only 156.25 µsec while the second buffer received the live data in real time. This left 1,093.75 µsec to display the digital information. And since the antenna did not move too much between sweeps, the actual placement was “good enough”. (The antenna rotated at 15 rpm which is about ¼ rps or 90 degrees in a second so even at the slower PRF of 267 (for 300 miles) the antenna only moved 1/3 of a degree which is much smaller than the horizontal beamwidth of the antenna.) The idea of double buffer can be extended to any number of buffers and called circular buffer because the buffers can be view as a circle with the consumer chasing the producer. In implementation this is usually a large buffer that is executed as a circle. (See Figure 10.) With this in mind we could always just build very large buffers. But there are two downsides. First each buffer takes up memory resources. Second managing the buffers takes overhead and thus affects performance, so only setting up what is needed is prudent. The config.sys file was where these were set up many years ago but that function has moved to the registry and can be modified for each application. Figure 10 Circular Buffer Alt Tag: Operation of a circular buffer The big question is how large a buffer do you need? At this point all of us are shouting, “ It depends ”. It depends on the average and peak production of data and the average consumption of the data. We can assume that consumption does not vary significantly but product has peaks. It also depends on our willingness to lose some data with no loss being the worst case. So let us say the average production rate is P and the average consumption rate is C. We know that P<=C else the buffer will overflow at some future point. Now let Pk be the peak production rate and let T be the maximum time that Pk will be greater than C. Then in order to not overflow the buffer it needs to be ( Pk − C ) x T in size. Here’s an example. Let P = 90 MBps and C = 100 MBps. So, we instantly see that P <= C which is good. Now Let Pk = 150 MBps and T = 2 second.

Chapter 5 Input Output Device Manager 38 Then ( Pk − C ) x T = ( 150 − 100 ) MBps x 2 sec ¿ 100 MB so we would need at least a 100 MB buffer in this case. For another take on buffers, watch Video 1 Sidebar I usually get some complaining at this point with a lot of “I’m not studying to be an engineer; I’m studying to be an Information Technologist”. But while you probably will never have to figure out a buffer size and build one, unless you go work in embedded, main frame, or real-time systems; this technique will serve you well in other areas of Information Technology. Take for example that you’ve been asked to help with a system that monitors video, and that video must be kept for 3 days just in case some litigation takes place so 3 days is the cut off. How much storage do you need to accomplish this? Well, this is exactly the same problem we just covered. And it is simple arithmetic! Video 1 Buffers https://www.youtube.com/watch?v=1cSou52VdE0 5.5.2 Disk Cache In Chapter 2 you learned about the memory hierarchy and cache. A disk cache is just a cache for the disk drive. Actually, despite the definition, it could very well be a cache for any secondary storage medium, but the prevalent version today is the hard disk drive so the name sticks. Many hard disks, tape drives, and solid-state drives include a disk cache as part of the drive (or drive controller). If on the drive it may also be referred to as the disk buffer. If the Operating System manages it in memory, then it is usually referred to as a soft disk cache. Like the other caches I wrote about, it holds data that has recently been read (for temporal locality of reference) and sometimes adjacent data areas that are likely to be accessed next (for spatial locality of reference). Unlike the other caches I wrote about, if in memory, this one is managed by the Operating System. If on the hard drive itself, then the hardware and firmware in the hard drive or its controller do the management and the Operating System may not even aware of the existence of the cache. Operating Systems should know about the cache, however, as there are some additional commands provided by the device driver and it would be pointless to manage a disk cache if one is already provided. Hard drives with a disk cache are more expensive than those without one—well that is really a no-brainer as to put it in place the hard drive must have the RAM to execute the cache. Current disk drives can come with between 8 and 256 MB of cache while solid state drives can come with up to 4 GB. Many cache systems attempt to predict what data will be requested next so they can populate the cache with it ahead of time. Disk Caches do add a certain amount of risk to the system since if the system crashes before the disk is updated, the updates will be lost. Recall this is not the case with other forms of cache since what is being cached is also volatile. Here we are dealing with long term storage. Because of this, writes happen frequently to help ensure data is not lost. In fact, many disk caches are write-thru caches which means reads are cached but writes are always sent directly to disk as well. If the write is not immediate then the cache is referred to as a write-back cache. Most device drivers come with cache flushing commands that the Operating

39 Chapter 5 Input Output Device Manager System can use to flush the device cache and the Operating System may execute flushes with any cache in memory. Generally, there is always some data stored that is not requested because the disk drive can start reading data as soon as the head is stable (hard drive and tape systems only since solid state drives can go directly to the data). Most systems begin to store this data in the cache and continue to do so until the requested data is accessible, then they also take a little more. We know the disk drive is a block device, so we are moving blocks of data around. Thus, to be useable, the data stored in a disk cache is stored in blocks as well. Current disk drives use block sizes between 512 bytes and 4kB so a disk cache can store up to 64k blocks of data (for a 256 MB cache with 512 byte block). Let this sink in and perhaps take some time to compare it to the cache sizes I spoke of in Chapter 2. For soft disk caches (those in memory managed by the Operating System), the data in the cache is a system resource and not allocated to a specific task. To be used by a task the data must be moved to the task’s memory space or a shared memory technique must be used to point to the data in the cache. If shared there might be a need to rotate the location of the disk cache to ensure it is always available. If a cache is used all the data goes through the cache, so like the caches I have already discussed, a replacement strategy is needed to kick data out of the cache so the next set can be accessed. A common strategy is a modified Least Frequently Used (LFU) scheme. The modification is a prediction on future use. If the data is expected to be used once then it is moved to the front (to be replaced next), if expected to be used again it is moved to the back. Any free cache is managed separately. Check Your Understanding. 1. On the follow list, which one would a Buffer NOT be the correct solution? a. During an input transfer, the input device transfers data into the buffer. When complete the task moves the block of data in the buffer to its user space then requests more data for the buffer. b. During stream transfers, the buffer can hold a line of data that is transferred when a carriage return is detected. c. Buffering ensures data is received by the consumer. d. Buffer can be used to bring in data to memory in advance of its request or to hold data for output until well after the request has been made. e. Buffering allows for differing rates of production and consumption and smoothes out peaks in input or output production. 2. A Disk Cache is always in memory. a. True b. False

Chapter 5 Input Output Device Manager 40 3. Disk Caches increase memory performance. a. True b. False

41 Chapter 5 Input Output Device Manager Summary Input and Output devices come in many forms and managing them is a tough task for the Operating System. The devices are also essential to the operation of a useful computer system since their absence precludes any interaction with humans and any ability to tailor or adjust the flow of a program. Each input or output device comes with the physical device, a device controller, and a device driver. The driver provides the Operating System code specific to the device. The device controller interfaces the device hardware to the computer system either directly to the CPU, through a bus (or channel), or as the bus. To manage the Input and Output devices, the Operating System through its Input and Output Device Manager maintains a table of devices attached to the computer. This table keeps track of what is available, which task owns the device, and which ones can use it. The Input and Output Device Manager also controls the device by communicating with the device through the device controller using Memory Mapped I/O or specific instructions. Applications get the services of the devices through System Calls to the Operating System. The Operating System may directly control the device and directly transfer data using polling or programmed I/O (also known as Busy Waiting). Here the device is being directly controlled by the CPU through code. Here the CPU cannot do anything else. The Operating system may also direct the control then wait for an interrupt. Here the CPU goes off and does other work while also waiting for input or output device. When the device is finished it sends a signal to the CPU notifying the CPU that it needs to be serviced. The same interaction can occur during the data transfer. And the data transfer can also be handled by another device called a DMA which sends and interrupt when the transfer is complete. Finally, the system can be improved through the use of Buffers and a Disk Cache. For another view of how it all fits together take a look at Video 2. Video 2 Basics of Input and Outputs https://www.youtube.com/watch?v=F18RiREDkwE Key Terms Amdahl’s Law –also known as Amdahl’s argument, it is a formula which gives the theoretical speedup for executing a task by applying more resources to the task Blocking call –blocking calls occur when a task cannot proceed without completion of the request, the task is paused. A threaded system may continue with another thread. Otherwise, execution is passed to the next task Buffer –a region of physical memory that is used to temporarily store data while it is being moved from one location to another Device controller –the interface between the CPU and Input or Output device. This is sometimes called a channel. The trend is to generalize the controller to specific interfaces called buses Device driver– software that speaks to the controller for the hardware Direct Memory Access –a method allowing a peripheral device to transfer data to or from the memory of a computer system using operations not under the control of the central processor

Chapter 5 Input Output Device Manager 42 Disk cache –a mechanism for improving the time it takes to read from or write to a hard disk Greenfield –a development effort that lacks constraints imposed by prior work Handshaking –during communication, the handshake is the agreed upon signals that must occur to ensure two devices can talk with each other Interrupts –a response by the processor to an event that needs attention from a peripheral Polling –the process where the computer or controlling device waits for an external device to check for its readiness or state, often with low-level hardware USB (Universal Serial Bus)–an industry standard that establishes specifications for connectors and protocols for the connection, communication, and power supply between computers and peripherals Write-thru caches –a cache that is implemented in such a fashion that any change of data in the cache (a write) are sent directly to the device being cached Chapter Check Point 1. Why are input and output important to a computer system? a. To provide for variation in program execution b. To increase the cost of the system c. To allow users to enter data into the system d. To allow users to see data from the system 2. What are the critical components of input and output devices? a. Device, Device Controller, Device Driver, Operating System b. Cache, Disk Cache, Operating System, Applications c. Device, Disk Cache, Operating System, Kernel d. Device Driver, Kernel, Application 3. What are the techniques to implement input and output? a. Polling and Interrupts b. Polling, Interrupts, and DMA c. Interrupts and DMA

43 Chapter 5 Input Output Device Manager d. Programmed I/O and DMA 4. How do problems with input or output and affect a computer? a. Performance issues including slow responsiveness and crashing b. Limits access to specific devices c. Prevents use of varied input d. Locks up the screen 5. What advantage does double buffering have over single buffering? a. Clear delineation between producer and consumer b. Twice as much space to use c. Producer can never overwrite the consumer d. No data can ever be lost 6. How do the critical I/O components interact? a. Through Interrupts or Polling b. Through busses c. Through channels or ports d. Through controllers 7. Summarize key concepts of Input and Output devices on computers? a. Trend more stringent standards and rate of new entrants is increasing b. Data rates are highly varied across devices c. Many options are available d. Very restrictive

Chapter 5 Input Output Device Manager 44 8. __________ is more efficient than interrupt-driven or programmed I/O for a multiple-word I/O transfer. a. Direct memory access b. Spatial locality c. Stack access d. Temporal locality 9. The Operating Systems role in I/O includes all the following EXCEPT: a. Provide Drivers b. Management c. Control d. Provide system calls e. Keep track of availability 10. What objectives do the Input Output Device Manager try to achieve? a. Efficiency and Improved Abstractions b. Standardization and Generality c. Efficiency and Generality d. Variability and uniqueness References None. Exercises 1. What are the two methods for handling I/O and how do they work? 2. What are the three methods for handling data transfers between I/O and the CPU and how do they work? 3. What are the purposes of buffering?

45 Chapter 5 Input Output Device Manager 4. Show three methods to connect a DMA to a system. 5. What is the difference between a block device and character device. Give an example of each. 6. What are various kinds of performance overheads associated with servicing an interrupt? 7. Compare and contrast memory mapped I/O to device control registers. 8. Compare and contrast blocking, non-blocking, and asynchronous I/O. 9. What is the difference between a device driver and a device controller? 10. What does the future of I/O look like in the gaming community? Problem Set 1. Outline how you would figure the performance increase for a system that you would replace the hard drive with one equal to the current one in all respects except it has disk caching. 2. For the following specifications would interrupt I/O or programmed I/O be better? Polling rate: 20 time units. I/O set up: 2time unit I/O operation: 50 time units Interrupt service time: 5 time unit 3. You have been contracted to come up with a method to access a new peripheral device that uses tactile methods to input information into a computer system. You have boiled down your research to polling and interrupts. Which method would you use and why? Laboratory Introduction In this lab you will explore I/O on one or more platforms. Remember these are free form labs and you are free to explore in detail one or more aspects or take the general approach and look a little at everything. You may also choose to go off and do anything of your choosing as long as it involves computer I/O. Go as deep as you believe is necessary, but I am expecting about 1 ½ hours of time on this assignment. About an hour in exploration and research and about a ½ hour in the write up. Remember to document what your intent was, what you did, and what you found.

Chapter 5 Input Output Device Manager 46 Feel free to add to the discussion group I opened in Blackboard. And feel free to create a thread for your particular examination. Background Input and output are why computers exist. All computers have I/O. We learned there is a wide range of I/O devices on the market, and they connect to the CPU via a bus network. Assignment You are to explore aspects of I/O on your computer or device. Feel free to go deep into a single item or explore generally. You may also decide to make it an academic exercise and look for information on the web. Here are some suggestions. Windows 1. Download and run the NTFSInfo utility from http://www.microsoft.com/technet/sysinternals/utilitiesindex.mspx. Explain the details of your hard drive organization (typically Drive C:) using this utility. To run this utility, open a command window, go to the directory where you have stored ntfsinfo.exe, and enter ntfsinfo.exe C:\. 2. Task Manager You can call up the Task Manager (CTRL+ALT+Delete) and look at the disk and network allocation for each process. You can also go down the list of processes and identify the ones that are strictly for I/O. Which I/O programs are launched on start up? What services are doing I/O? What groups do they belong to? 3. Start Menu. Look at your start menu and identify the programs that are strictly for I/O. Do you know what each of them does? 4. Look at some settings (Start  Setting) Under System you can configure display, Sound, and Storage. What are your defaults. What is not the default. Play around with these and see what they do. (Careful – make a note of a setting before you change it – so you can change it back). Under Devices you can configure Bluetooth, printers, mouse, touchpad, typing, etc. Under Network & Internet you can monitor the network status, configure Wi-Fi, Ethernet, etc. Under Personalization you can change how your user experience is presented. Linux df is a command that displays the amount of disk space available on the file system containing each file name argument. Read man page of df command. Run the command df to find out how many disk blocks are available and how many are in use. Does the sum of these equals the total number of disk blocks on the disk? If not, explain why there is a difference. Next run the

47 Chapter 5 Input Output Device Manager command df –i to find out how many inodes are available and in use. Now create a new file with just a few characters in it, and again run df and df –i commands. Explain the effect of creating this new file. Now increase the size of this new file by entering a large number (> 5000) of characters, and again run df and df –I commands. Explain the effect of increasing the size of the new file. To work in Linux, you’ll need “procinfo” and “lsscsi” which comes with Ubuntu, Fedora, and Manjaro distributions. You can find your hard drives in /dev/sd they are usually labeled as a, b, etc. as sda, sdb, etc. Partitions are an appended number so sda1 for partition 1 on the sda drive. You can use mount to get the drive as in mount | grep /dev/sd this will list the hard drive and partition and type. The grep command makes it so you don’t have to give the exact name. It does that work for you. You also get the location and other information. Lsblk lists the block devices, their mount point, and other information. While fdisk can manipulate the disk partition it can also just view information as well using the - l switch. (fdisk -l). You may need to pipe it through less to show everything. Lspci gives all the PCI devices on the computer and lsusb gives all the USB devices. And lsscsi gives SCSI devices. The lsdev displays information on all the installed devices. You may want to pipe through less. The lshw displays information on all devices. Again, pipe through less. And hwinfo gives all hardware information. You must pipe through less here or use some switch like “–short” General 1. Evaluation of a System Here is a partial product description of a Dell System I put together. This is a high-end system (about $44k work of it). Use this table to answer the questions below and perhaps guide some research about it. Option Selection Processor Dual Intel Xeon Platinum 8280 2.7GHz,(4.0GHz Turbo, 28C, 10.4GT/s 3UPI, 38.5MB, HT (205W)) DDR4-2933 Chassis Options Precision 7820 Tower 950W Chassis CL Graphics Card Radeon™ Pro WX 2100, 2GB, FH, 3 mP (7X20T)

Chapter 5 Input Output Device Manager 48 Option Selection Memory 512GB 4x128GB 2666MHz Intel® Optane™ DC Persistent Memory (8x16GB DDR4 2666MHz RDIMM Memory cache) Operating System (Boot) Drive SATA/SAS Hard Drive/Solid State Drive Storage Drive Controllers Integrated Intel AHCI chipset SATA Hard Drive 3.5" 1TB 7200rpm SATA Hard Drive PCIe I/O Cards Thunderbolt 3 PCIe card - 2 Type C Ports, 1 DP in Serial Port/PS2 Adapter MOD,PWA,PWR,SER,FH,PWS2 Resource DVD Precision T5820/T7820/T7920 Resource DVD Describe the I/O devices. iPhone Investigate the devices you have from your Apple ID account page. Android I’d be interested in knowing more about this one. Extra Reading For extra Reading visit the following Wikipedia topics by visiting www.wikipedia.org and entering the key work below of interest to you. Overview of Input and Output  Amdahl's Law  ASCII  Baud  Commodore PET  Commodore VIC 20  Floppy Disk  Hard Disk  Input Device  Input/ Output

49 Chapter 5 Input Output Device Manager  Modem  Output Device  Unicode  USB Input and Output Features  Accelerated Graphics Port  Bus (computing)  Centronics  Extended Industry Standard Architecture  HDMI  IBM PS/2  IEEE 1394  Industry Standard Architecture  Low Pin Count  LPC bus  Micro Channel Architecture  Motherboard  Parallel ATA (IDE)  Parallel Port  PCI  PCI Express  PCI-X  Peripheral Component Interconnect  Phone Connector (audio)  PS/2 port  SCSI  Serial ATA  Serial Peripheral Interface  Serial Peripheral Interface  Serial Port  VESA Local Bus  Video Electronics Standards Association Operating System Organization  System Call  Windows Registry Communicating with Input and Output  Direct Memory Access  Interrupt  Interrupt request (PC architecture)  Message Signaled Interrupts  Polling (computer science) Technology to Improve Input and Output  Circular Buffer  Data Buffer  Disk Buffer  Disk Cache

Chapter 5 Input Output Device Manager 50  Multiple Buffering