DOCSLIB.ORG

Principles of Operating Systems

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Principles of Operating Systems Principles of Operating Systems Lecture 1 - Introduction and overview, operating system structure Ardalan Amiri Sani ([email protected]) [lecture slides contains some content adapted from : Silberschatz textbook authors, Anderson textbook authors, John Kubiatowicz (Berkeley), John Ousterhout(Stanford), previous slides by Prof. Nalini Venkatasubramanian, http://www-inst.eecs.berkeley.edu/~cs162/ and others] 1 Staff • Instructor • Ardalan Amiri Sani ([email protected]) 2 Staff Teaching Assistants: Saehanseul Yi <[email protected]> Claudio Parra <[email protected]> Reader: Mingyi Chen <[email protected]> 3 Course logistics and details • Course web page - • https://www.ics.uci.edu/~ardalan/courses/os/index.html • Discussions • Wednesday 5:00-5:50pm (Zoom link on Canvas) • Friday 6:00-6:50pm (Zoom link on Canvas) 4 Course logistics and details • Textbook: Operating System Concepts -- Ninth Edition A. Silberschatz, P.B. Galvin, and G. Gagne (Tenth, Eighth, Seventh, Sixth, and Fifth editions are fine as well). • Other suggested Books • Operating Systems: Principles and Practice, by T. Anderson and M. Dahlin (second edition) • Modern Operating Systems, by Tanenbaum (Third edition) • Principles of Operating Systems, by L.F. Bic and A.C. Shaw, 2003. • Operating Systems: Three Easy Pieces, by Remzi H. Arpaci-Dusseau and Andrea C. Arpaci-Dusseau 5 Course logistics and details •Homeworks and Assignments • 4 written homeworks in the quarter • 1 programming assignment (knowledge of C). • Multistep assignment – don’t start in last week of classes!!! • Late homework policy. • Lose 10% of grade for every late hour. • All submissions will be made using Gradescope •Tests • Midterm – Friday, Week 6 (during class time) • Final Exam – per UCI course catalog (Friday, 3/19, 8am-10am) 6 Grading Policy •Written Homeworks - 20% • 4 written homeworks each worth 5% of the final grade. •Project - 10% of the final grade •Midterm - 30% of the final grade •Final exam - 40% of the final grade •Curve will be used if needed. 7 Lecture Schedule •Week 1 • Introduction to Operating Systems, Computer System Structures, Operating System Structures •Week 2 • Processes and Threads •Week 3 • Processes and Threads, and CPU Scheduling •Week 4 • Scheduling •Week 5 • Process Synchronization 8 Lecture Schedule •Week 6 • Deadlocks, Midterm exam •Week 7 • Memory Management •Week 8 • Memory Management, Virtual Memory •Week 9 • File Systems Interface and Implementation •Week 10 • I/O Subsystems 9 Classes I will most likely miss • 2/24/2021: conference program committee meeting (Will announce later if other lectures are to be missed) • Will announce later the plan for missed lectures • Sometimes, the TA will replace me on those dates 10 Office hours • Instructor • Fridays 1:00pm-2:00pm (Same Zoom link as the one used for lectures, available on Canvas) • TA • Tuesdays 10:00am-11:00am (Zoom link on Canvas) Office hours will start on the second week of classes 11 Piazza • https://piazza.com/uci/winter2021/compsci143a 12 Slides • Will upload first draft of the slides for all of the week on Monday • Might (and most likely will) update slides for each class before the class 13 Overview •What is an operating system? •Operating systems history •Computer system and operating system structure 14 What is an Operating System? 15 What is an Operating System? •OS is the software that acts an intermediary between the applications and computer hardware. 16 Computer System Components •Hardware • Provides basic computing resources (CPU, memory, I/O devices). •Operating System • Controls and coordinates the use of hardware among application programs. •Application Programs • Solve computing problems of users (compilers, database systems, video games, business programs). •Users • People, other computers 17 Abstract View of System User User User User 1 2 3 ... n compiler assembler Text editor Database system Application Programs Operating System Computer Hardware 18 Operating system roles •Referee • Resource allocation among users, applications • Isolation of different users, applications from each other • Communication between users, applications 19 Operating system roles •Illusionist • Each application appears to have the entire machine to itself • Infinite number of processors, (near) infinite amount of memory, reliable storage, reliable network transport 20 Operating system roles •Glue • Libraries, user interface widgets, … • Reduces cost of developing software 21 Example: file systems •Referee • Allocates storage space for files for each user • Prevent users from accessing each other’s files without permission •Illusionist • Files can grow (nearly) arbitrarily large • Files persist even when the machine crashes in the middle of a save •Glue • Named directories, printf, … 22 OS challenges 23 OS challenges •Reliability • Does the system do what it was designed to do? 24 OS challenges •Availability • What portion of the time is the system working? • Mean Time To Failure (MTTF), Mean Time to Repair 25 OS challenges •Security • Can the system be compromised by an attacker? 26 OS challenges •Privacy • Data is accessible only to authorized users 27 OS challenges •Performance • Latency/response time • How long does an operation take to complete? • Throughput • How many operations can be done per unit of time? • Overhead • How much extra work is done by the OS? • Fairness • How equal is the performance received by different users? • Predictability • How consistent is the performance over time? 28 OS challenges •Portability • For programs: • Application programming interface (API) • For the kernel • Hardware abstraction layer 29 OS needs to keep pace with hardware improvements $/ 30 Why should I study Operating Systems? 31 Why should I study Operating Systems? • Need to understand interaction between the hardware and software • Need to understand basic principles in the design of computer systems • efficient resource management, security, flexibility 32 Why should I study Operating Systems? • Because it enables you to do things that are difficult/impossible otherwise. 33 Example: Rio: I/O sharing implemented in the operating system kernel 34 Observation: I/O devices important for personal computers 35 A personal computer today ● 64 GB internal storage (extended by microSD) ● Super AMOLED display ● 4G LTE ● Capacitive touchscreen (multitouch) ● S pen ● Audio (speaker, microphone) ● Super AMOLED display (1080 x 1920 pixels, 5.7 inches ● Vibration (~386 ppi pixel density)) ● S pen ● capacitive touchscreen, 16M colors, multitouch ● 13 MP front camera ● speaker, mic, audio jack ● 2 MP back camera ● vibration ● Accelerometer ● NFC ● Gyroscope ● WiFi ● Proximity sensor ● bluetooth ● Compass ● Infrared ● Barometer ● 13 MP front camera ● Temperature sensor ● 2 MP back camera ● Humidity sensor ● Adreno 330 GPU ● Gesture sensor ● Accelerometer ● GPS ● gyro ● 4G LTE ● proximity sensor ● NFC ● compass ● WiFi ● barometer ● Bluetooth ● temperature sensor ● Infrared ● humidity sensor ● 64 GB internal storage (extended by microSD) ● gesture sensor ● Adreno 330 GPU ● GPS ● Hexagon DSP ● Hexagon DSP ● Multimedia processor ● Audio/Video HW accelerator 36 ● Multimedia processor A personal computer today ● Super AMOLED display ● Capacitive touchscreen (multitouch) ● Audio (speaker, microphone) ● Vibration interaction ● S pen ● 13 MP front camera ● 2 MP back camera ● Accelerometer ● Gyroscope ● Proximity sensor ● Compass ● Barometer ● Temperature sensor ● Humidity sensor ● Gesture sensor ● GPS ● 4G LTE ● NFC ● WiFi ● Bluetooth ● Infrared ● 64 GB internal storage (extended by microSD) ● Adreno 330 GPU ● Hexagon DSP ● Multimedia processor 37 A personal computer today ● Super AMOLED display ● Capacitive touchscreen (multitouch) ● Audio (speaker, microphone) ● Vibration ● S pen ● 13 MP front camera ● 2 MP back camera ● Accelerometer ● Gyroscope ● Proximity sensor ● Compass ● Barometer sensing ● Temperature sensor ● Humidity sensor ● Gesture sensor ● GPS ● 4G LTE ● NFC ● WiFi ● Bluetooth ● Infrared ● 64 GB internal storage (extended by microSD) ● Adreno 330 GPU ● Hexagon DSP ● Multimedia processor 38 A personal computer today ● Super AMOLED display ● Capacitive touchscreen (multitouch) ● Audio (speaker, microphone) ● Vibration ● S pen ● 13 MP front camera ● 2 MP back camera ● Accelerometer ● Gyroscope ● Proximity sensor ● Compass ● Barometer ● Temperature sensor ● Humidity sensor connectivity, ● Gesture sensor ● GPS storage ● 4G LTE ● NFC ● WiFi ● Bluetooth ● Infrared ● 64 GB internal storage (extended by microSD) ● Adreno 330 GPU ● Hexagon DSP ● Multimedia processor 39 A personal computer today ● Super AMOLED display ● Capacitive touchscreen (multitouch) ● Audio (speaker, microphone) ● Vibration ● S pen ● 13 MP front camera ● 2 MP back camera ● Accelerometer ● Gyroscope ● Proximity sensor ● Compass ● Barometer ● Temperature sensor ● Humidity sensor ● Gesture sensor ● GPS ● 4G LTE ● NFC ● WiFi ● Bluetooth ● Infrared ● 64 GB internal storage (extended by microSD) ● Adreno 330 GPU ● Hexagon DSP ● Multimedia processor acceleration 40 Multiple computers for unique I/O 41 Multiple computers for unique I/O 42 Multiple computers for unique I/O 43 I/O sharing 44 How to build this? Application Daemons, Libraries User space Kernel Device driver I/O device 45 Application layer Application Application Daemons, Libraries Daemons, Libraries User space User space Kernel Kernel Device driver Device driver ● IP Webcam I/O device ● Wi-Fi Speaker I/O device ● MightyText Client Server 46 Do not meet our criteria • High engineering effort Application •
Load more

Recommended publications
  • Security and Performance Analysis of Custom Memory Allocators Tiffany
    Security and Performance Analysis of Custom Memory Allocators by Tiffany Tang Submitted to the Department of Electrical Engineering and Computer Science in partial fulfillment of the requirements for the degree of Master of Engineering in Electrical Engineering and Computer Science at the MASSACHUSETTS INSTITUTE OF TECHNOLOGY September 2019 c Massachusetts Institute of Technology 2019. All rights reserved. Author.............................................................. Department of Electrical Engineering and Computer Science June 10, 2019 Certified by. Howard E. Shrobe Principal Research Scientist and Associate Director of Security, CSAIL Thesis Supervisor Certified by. Hamed Okhravi Senior Technical Staff, MIT Lincoln Laboratory Thesis Supervisor Accepted by . Katrina LaCurts, Chair, Masters of Engineering Thesis Committee 2 DISTRIBUTION STATEMENT A. Approved for public release. Distribution is unlimited. This material is based upon work supported by the Assistant Secretary of Defense for Research and Engineering under Air Force Contract No. FA8702-15-D-0001. Any opinions, findings, conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the Assistant Secre- tary of Defense for Research and Engineering. 3 Security and Performance Analysis of Custom Memory Allocators by Tiffany Tang Submitted to the Department of Electrical Engineering and Computer Science on June 10, 2019, in partial fulfillment of the requirements for the degree of Master of Engineering in Electrical Engineering and Computer Science Abstract Computer programmers use custom memory allocators as an alternative to built- in or general-purpose memory allocators with the intent to improve performance and minimize human error. However, it is difficult to achieve both memory safety and performance gains on custom memory allocators.
    [Show full text]
  • CSE421 Midterm Solutions —SOLUTION SET— 09 Mar 2012
    CSE421 Midterm Solutions —SOLUTION SET— 09 Mar 2012 This midterm exam consists of three types of questions: 1. 10 multiple choice questions worth 1 point each. These are drawn directly from lecture slides and intended to be easy. 2. 6 short answer questions worth 5 points each. You can answer as many as you want, but we will give you credit for your best four answers for a total of up to 20 points. You should be able to answer the short answer questions in four or five sentences. 3. 2 long answer questions worth 20 points each. Please answer only one long answer question. If you answer both, we will only grade one. Your answer to the long answer should span a page or two. Please answer each question as clearly and succinctly as possible. Feel free to draw pic- tures or diagrams if they help you to do so. No aids of any kind are permitted. The point value assigned to each question is intended to suggest how to allocate your time. So you should work on a 5 point question for roughly 5 minutes. CSE421 Midterm Solutions 09 Mar 2012 Multiple Choice 1. (10 points) Answer all ten of the following questions. Each is worth one point. (a) In the story that GWA (Geoff) began class with on Monday, March 4th, why was the Harvard student concerned about his grade? p He never attended class. He never arrived at class on time. He usually fell asleep in class. He was using drugs. (b) All of the following are inter-process (IPC) communication mechanisms except p shared files.
    [Show full text]
  • A Bare Machine Sensor Application for an ARM Processor
    A Bare Machine Sensor Application for an ARM Processor Alexander Peter, Ramesh K. Karne and Alexander L. Wijesinha Department of Computer & Information Sciences Towson, MD 21252 [email protected], (rkarne, awijesinha)@towson.edu Abstract- Sensor devices that monitor environmental changes in In order to build a bare machine temperature sensor device temperature, sound, light, vibration and pressure usually run application, it requires several components as shown in Fig. 1. applications that require the support of a small operating system, A brief functional description of this application is as follows. lean kernel, or an embedded system. This paper presents a The application is loaded from the SD Card interface (Label 9) methodology for developing sensor device applications that can into memory using U-Boot. A temperature sensor (Label 1) is be directly run on the bare hardware without any need for middleware. Such bare sensor device applications only depend plugged into the ADB to monitor the current room on the underlying processor architecture, enabling them to run temperature with a sensing granularity of 900 microseconds. on a variety of devices. The methodology is used for developing, As the temperature changes, its value (Label 8) and a graphic designing, and implementing a temperature sensor application image (Label 7) is displayed on the LCD screen (Label 2). An that runs on an ARM processor. The same methodology can be output console is used to debug the inner working of the ADB used to build other bare machine sensor device applications for and temperature (Label 3). An LED light (Label 4) provides a ARM processors, and is easily extended to different processor visual indication of temperature sensor operation.
    [Show full text]
  • Paging: Smaller Tables
    20 Paging: Smaller Tables We now tackle the second problem that paging introduces: page tables are too big and thus consume too much memory. Let’s start out with a linear page table. As you might recall1, linear page tables get pretty 32 12 big. Assume again a 32-bit address space (2 bytes), with 4KB (2 byte) pages and a 4-byte page-table entry. An address space thus has roughly 232 one million virtual pages in it ( 212 ); multiply by the page-table entry size and you see that our page table is 4MB in size. Recall also: we usually have one page table for every process in the system! With a hundred active processes (not uncommon on a modern system), we will be allocating hundreds of megabytes of memory just for page tables! As a result, we are in search of some techniques to reduce this heavy burden. There are a lot of them, so let’s get going. But not before our crux: CRUX: HOW TO MAKE PAGE TABLES SMALLER? Simple array-based page tables (usually called linear page tables) are too big, taking up far too much memory on typical systems. How can we make page tables smaller? What are the key ideas? What inefficiencies arise as a result of these new data structures? 20.1 Simple Solution: Bigger Pages We could reduce the size of the page table in one simple way: use bigger pages. Take our 32-bit address space again, but this time assume 16KB pages. We would thus have an 18-bit VPN plus a 14-bit offset.
    [Show full text]
  • Operating Systems Privileged Instructions
    November 2, 1999 Operating Systems • Operating systems manage processes and resources • Processes are executing instances of programs may be the same or different programs process 1 process 2 process 3 code code code data data data SV SV SV state vector: information necessary to start, stop, and restart the process • State vector: registers, program counter, memory mgmt registers, etc. user-level processes assembly & high-level languages operating system, “kernel” machine language & system calls bare machine machine language Copyright 1997 Computer Science 217: Operating System Page 187 November 2, 1999 Privileged Instructions • Machines have two kinds of instructions 1. “normal” instructions, e.g., add, sub, etc. 2. “privileged” instructions, e.g., initiate I/O switch state vectors or contexts load/save from protected memory etc. • Operating systems hide privileged instructions and provide virtual instructions to access and manipulate virtual resources, e.g., I/O to and from disc files • Virtual instructions are system calls • Operating systems interpret virtual instructions Copyright 1997 Computer Science 217: Operating System Page 188 November 2, 1999 Processor Modes • Machine level typically has 2 modes, e.g., “user” mode and “kernel” mode • User mode processor executes “normal” instructions in the user’s program upon encountering a “privileged” instruction, processor switches to kernel mode, and the operating system performs a service • Kernel mode processor executes both normal and privileged instructions • User-to-kernel switch
    [Show full text]
  • Virtual Memory Basics
    Operating Systems Virtual Memory Basics Peter Lipp, Daniel Gruss 2021-03-04 Table of contents 1. Address Translation First Idea: Base and Bound Segmentation Simple Paging Multi-level Paging 2. Address Translation on x86 processors Address Translation pointers point to objects etc. transparent: it is not necessary to know how memory reference is converted to data enables number of advanced features programmers perspective: Address Translation OS in control of address translation pointers point to objects etc. transparent: it is not necessary to know how memory reference is converted to data programmers perspective: Address Translation OS in control of address translation enables number of advanced features pointers point to objects etc. transparent: it is not necessary to know how memory reference is converted to data Address Translation OS in control of address translation enables number of advanced features programmers perspective: transparent: it is not necessary to know how memory reference is converted to data Address Translation OS in control of address translation enables number of advanced features programmers perspective: pointers point to objects etc. Address Translation OS in control of address translation enables number of advanced features programmers perspective: pointers point to objects etc. transparent: it is not necessary to know how memory reference is converted to data Address Translation - Idea / Overview Shared libraries, interprocess communication Multiple regions for dynamic allocation
    [Show full text]
  • MIPS: the Virtual Machine
    2 MIPS: The Virtual Machine Objectives After this lab you will know: • what are synthetic instructions • how synthetic instructions expand to sequences of native instructions • how MIPS addresses the memory Note: You can use PCSpim using the menu items instead of individual console commands. Familiarize yourself with PCSpim. Introduction MIPS is a ‘typical’ RISC architecture: it has a simple and regular instruction set, only one memory addressing mode (base plus displacement) and instructions are of fixed size (32 bit). Surprisingly, it is not very simple to write assembly programs for MIPS (and for any RISC machine for that matter). The reason is that programming is not supposed to be done in assembly language. The instruction sets of RISC machines have been designed such that: • they are good targets for compilers (thus simplifying the job of compiler writers) • they allow a very efficient implementation (pipelining) Pipelining means that several instructions are present in the CPU at any time, in various stages of execution. Because of this situation it is possible that some sequences of instructions just don’t work the way they are listed on paper. For instance Ex 1: lw $t0, 0($gp) # $t0 <- M[$gp + 0] add $t2, $t2, $t0 # $t2 <- $t2 + $t0 loads a word from memory in register $t0 and then adds it, in the next instruction, to register $t2. The prob- lem here is that, by the time the add instruction is ready to use register $t0, the value of $t0 has not changed yet. This is not to say that the load instruction (lw) has not completed.
    [Show full text]
  • Address Translation
    CS 152 Computer Architecture and Engineering Lecture 8 - Address Translation John Wawrzynek Electrical Engineering and Computer Sciences University of California at Berkeley http://www.eecs.berkeley.edu/~johnw http://inst.eecs.berkeley.edu/~cs152 9/27/2016 CS152, Fall 2016 CS152 Administrivia § Lab 2 due Friday § PS 2 due Tuesday § Quiz 2 next Thursday! 9/27/2016 CS152, Fall 2016 2 Last time in Lecture 7 § 3 C’s of cache misses – Compulsory, Capacity, Conflict § Write policies – Write back, write-through, write-allocate, no write allocate § Multi-level cache hierarchies reduce miss penalty – 3 levels common in modern systems (some have 4!) – Can change design tradeoffs of L1 cache if known to have L2 § Prefetching: retrieve memory data before CPU request – Prefetching can waste bandwidth and cause cache pollution – Software vs hardware prefetching § Software memory hierarchy optimizations – Loop interchange, loop fusion, cache tiling 9/27/2016 CS152, Fall 2016 3 Bare Machine Physical Physical Address Inst. Address Data Decode PC Cache D E + M Cache W Physical Memory Controller Physical Address Address Physical Address Main Memory (DRAM) § In a bare machine, the only kind of address is a physical address 9/27/2016 CS152, Fall 2016 4 Absolute Addresses EDSAC, early 50’s § Only one program ran at a time, with unrestricted access to entire machine (RAM + I/O devices) § Addresses in a program depended upon where the program was to be loaded in memory § But it was more convenient for programmers to write location-independent subroutines How
    [Show full text]
  • Microkernels Meet Recursive Virtual Machines
    Microkernels Meet Recursive Virtual Machines Bryan Ford Mike Hibler Jay Lepreau Patrick Tullmann Godmar Back Stephen Clawson Department of Computer Science, University of Utah Salt Lake City, UT 84112 [email protected] http://www.cs.utah.edu/projects/flux/ Abstract “vertically” by implementing OS functionality in stackable virtual machine monitors, each of which exports a virtual This paper describes a novel approach to providingmod- machine interface compatible with the machine interface ular and extensible operating system functionality and en- on which it runs. Traditionally, virtual machines have been capsulated environments based on a synthesis of micro- implemented on and export existing hardware architectures kernel and virtual machine concepts. We have developed so they can support “naive” operating systems (see Fig- a software-based virtualizable architecture called Fluke ure 1). For example, the most well-known virtual machine that allows recursive virtual machines (virtual machines system, VM/370 [28, 29], provides virtual memory and se- running on other virtual machines) to be implemented ef- curity between multiple concurrent virtual machines, all ficiently by a microkernel running on generic hardware. exporting the IBM S/370 hardware architecture. Further- A complete virtual machine interface is provided at each more, special virtualizable hardware architectures [22, 35] level; efficiency derives from needing to implement only have been proposed, whose design goal is to allow virtual new functionality at each level. This infrastructure allows machines to be stacked much more efficiently. common OS functionality, such as process management, demand paging, fault tolerance, and debugging support, to This paper presents a new approach to OS extensibil- be provided by cleanly modularized, independent, stack- ity which combines both microkernel and virtual machine able virtual machine monitors, implemented as user pro- concepts in one system.
    [Show full text]
  • A Lean USB File System for Bare Machine Applications
    A Lean USB File System for Bare Machine Applications Songjie Liang Ramesh K. Karne Alexander L. Wijesinha Department of Computer and Department of Computer and Department of Computer and Information Sciences Information Sciences Information Sciences Towson University Towson University Towson University Towson, Maryland, USA Towson, Maryland, USA Towson, Maryland, USA [email protected] [email protected] [email protected] Abstract USB file management systems for mass storage are and then describe the design of the bare file system, supported on many platforms and commonly used today by including disk map, root directory, sequencing operations, a variety of applications. These file systems vary depending tasks, and user interface. The file system runs on an Intel upon the underlying operating system and environment. We x86 based bare PC. For comparison purposes, essentially consider the design of a USB file system that is the same system, but with minimal system calls, was independent of any operating system or application implemented on a Linux OS. environment. Specifically, we describe the design and development of a lean USB file system for supporting bare The rest of the paper is organized as follows. Section II PC applications that run with no OS or kernel support of considers related work, and Section III describes the lean any kind, and give details of its architecture, design, and file management system. Section IV discusses architecture implementation. Our design leverages the design and issues, Section V narrates some design details, Section characteristics and inherent features of USB mass storage. VI shows implementation, Section VII outlines novel Bare machine USB file management systems enable features of our approach, Section VIII deals with functional computer applications to access mass storage at run-time operation and testing, and Section IX presents the without the operating system and environmental conclusion.
    [Show full text]
  • On Design and Implementation of an Embedded System for Neural-Machine Interface for Artificial Legs
    University of Rhode Island DigitalCommons@URI Open Access Dissertations 2013 On Design and Implementation of an Embedded System for Neural-Machine Interface for Artificial Legs Xiaorong Zhang University of Rhode Island, [email protected] Follow this and additional works at: https://digitalcommons.uri.edu/oa_diss Recommended Citation Zhang, Xiaorong, "On Design and Implementation of an Embedded System for Neural-Machine Interface for Artificial Legs" (2013). Open Access Dissertations. Paper 23. https://digitalcommons.uri.edu/oa_diss/23 This Dissertation is brought to you for free and open access by DigitalCommons@URI. It has been accepted for inclusion in Open Access Dissertations by an authorized administrator of DigitalCommons@URI. For more information, please contact [email protected]. ON DESIGN AND IMPLEMENTATION OF AN EMBEDDED SYSEM FOR NEURAL-MACHINE INTERFACE FOR ARTIFICIAL LEGS BY XIAORONG ZHANG A DISSERTATION SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY IN COMPUTER ENGINEERING UNIVERSITY OF RHODE ISLAND 2013 DOCTOR OF PHILOSOPHY DISSERTATION OF XIAORONG ZHANG APPROVED: Dissertation Committee: Major Professor Qing Yang He Huang Joan Peckham Nasser H. Zawia DEAN OF THE GRADUATE SCHOOL UNIVERSITY OF RHODE ISLAND 2013 ABSTRACT According to limb loss statistics, there are over one million leg amputees in the US whose lives are severely impacted by their conditions. In order to improve the quality of life of patients with leg amputations, neural activities have been studied by many researchers for intuitive prosthesis control. The neural signals collected from muscles are electromyographic (EMG) signals, which represent neuromuscular activities and are effective bioelectrical signals for expressing movement intent.
    [Show full text]
  • User|Mjs Guide
    Tivoli® Storage Manager FastBack for Bare Machine Recovery Version 6.1.1.0 Tivoli Storage Manager FastBack for Bare Machine Recovery User's Guide SC27-2308-05 Tivoli® Storage Manager FastBack for Bare Machine Recovery Version 6.1.1.0 Tivoli Storage Manager FastBack for Bare Machine Recovery User's Guide SC27-2308-05 Note Before using this information and the product it supports, read the information in “Notices” on page 35. This edition applies to version 6, release 1, modification 1 of IBM Tivoli Storage Manager FastBack for Bare Machine Recovery (product number 5724-U95) and to all subsequent releases and modifications until otherwise indicated in new editions. This edition replaces SC27-2308-04. © Copyright IBM Corporation 2008, 2010. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Preface ...............v Using the FastBack for Bare Machine Recovery CD Who should read this guide .........v for bare machine recovery on your Windows system 13 Publications ..............v Using the Any-to-Any Hardware Restore utility 16 Support information ............v Restoring a disk using the non-system disk restore 18 Getting technical training .........v Scenarios using Tivoli Storage Manager FastBack . 19 Searching knowledge bases ........v Using a single system for client and server ....20 Contacting IBM Software Support ......vi | Restoring from a Tivoli Storage Manager FastBack Conventions used in this information .....viii | repository located on a Tivoli Storage Manager Documentation changes ..........viii || server ................20 | Using Tivoli Storage Manager FastBack for Bare Chapter 1. Overview .........1 || Machine Recovery on your Linux system ....21 Supported environments ..........2 Access permissions ............5 Chapter 4.
    [Show full text]