1 Mobile Systems Richard Yang. 2 Admin. r Homework 4 m due Friday Dec. 8th.

Slides:



Advertisements
Similar presentations
How to use TinyOS Jason Hill Rob Szewczyk Alec Woo David Culler An event based execution environment for Networked Sensors.
Advertisements

A System Architecture for Tiny Networked Devices
Threads, SMP, and Microkernels
Threads, SMP, and Microkernels Chapter 4. Process Resource ownership - process is allocated a virtual address space to hold the process image Scheduling/execution-
Chapter 4 Threads, SMP, and Microkernels Patricia Roy Manatee Community College, Venice, FL ©2008, Prentice Hall Operating Systems: Internals and Design.
Contiki A Lightweight and Flexible Operating System for Tiny Networked Sensors Presented by: Jeremy Schiff.
Jason Hill, Robert Szewczyk, Alec Woo Spring 2000 TinyOS Operating System for Networked Sensors Networked SensorsSystem Structure Composing Components.
Tiny OS Optimistic Lightweight Interrupt Handler Simon Yau Alan Shieh CS252, CS262A, Fall The.
A System Architecture for Tiny Networked Devices Jason Hill U.C. Berkeley 9/22/2000.
Chapter 13 Embedded Systems
1 TinyOS Mohammad Rahimi CSCI599-Spring Motivation  The new class of distributed tiny devices  The new generation of software.
TinyOS Software Engineering Sensor Networks for the Masses.
Real-Time Kernels and Operating Systems. Operating System: Software that coordinates multiple tasks in processor, including peripheral interfacing Types.
Sensor Node Architecture Issues Stefan Dulman
1 Chapter 13 Embedded Systems Embedded Systems Characteristics of Embedded Operating Systems.
Chapter 13 Embedded Operating Systems Eighth Edition By William Stallings Operating Systems: Internals and Design Principles.
Real-Time Software Design Yonsei University 2 nd Semester, 2014 Sanghyun Park.
ECE 526 – Network Processing Systems Design Network Processor Architecture and Scalability Chapter 13,14: D. E. Comer.
A System Architecture for Networked Sensors Jason Hill, Robert Szewczyk, Alec Woo, Seth Hollar, David Culler, Kris Pister
April 15, 2005TinyOS: A Component Based OSPage 1 of 27 TinyOS A Component-Based Operating System for Networked Embedded Systems Tom Bush Graduate College.
Low-Power Wireless Sensor Networks
Eric Keller, Evan Green Princeton University PRESTO /22/08 Virtualizing the Data Plane Through Source Code Merging.
Energy-Efficient Soft Real-Time CPU Scheduling for Mobile Multimedia Systems Wanghong Yuan, Klara Nahrstedt Department of Computer Science University of.
Chapter 4 Threads, SMP, and Microkernels Patricia Roy Manatee Community College, Venice, FL ©2008, Prentice Hall Operating Systems: Internals and Design.
Overview of: System Architecture Directions for Networked Sensors John Kerwin CSE 291 Sensor Networks Paper by: Jason Hill, Robert Szewczyk, Alec Woo,
Dhanshree Nimje Smita Khartad
System Architecture Directions for Networked Sensors Jason Hill, Robert Szewczyk, Alec Woo, Seth Hollar, David Culler, Kris Pister Presented by Yang Zhao.
Reference: Ian Sommerville, Chap 15  Systems which monitor and control their environment.  Sometimes associated with hardware devices ◦ Sensors: Collect.
Simulation of Distributed Application and Protocols using TOSSIM Valliappan Annamalai.
Part 2 TinyOS and nesC Programming Selected slides from:
1 Mobile File Systems: Disconnected and Weakly Connected File Systems 3/29/2004 Richard Yang.
Threads, SMP, and Microkernels Chapter 4. Process Resource ownership - process is allocated a virtual address space to hold the process image Scheduling/execution-
1 Threads, SMP, and Microkernels Chapter Multithreading Operating system supports multiple threads of execution within a single process MS-DOS.
System Architecture Directions for Networked Sensors Jason Hill, Robert Szewczyk, Alec Woo, Seth Hollar, David Culler, Kris Pister Presenter: James.
Xiong Junjie Node-level debugging based on finite state machine in wireless sensor networks.
TinyOS Sandeep Gupta. Operating System (OS) What is an OS? Main functions  Process management  Memory management  Resource management Traditional OSs.
System Architecture Directions for Networked Sensors.
CSE466 - Fall What is an Embedded System  Its not a desktop system  Fixed or semi-fixed functionality (not user programmable)  Lacks some or.
Time Management.  Time management is concerned with OS facilities and services which measure real time.  These services include:  Keeping track of.
Why does it need? [USN] ( 주 ) 한백전자 Background Wireless Sensor Network (WSN)  Relationship between Sensor and WSN Individual sensors are very limited.
Software Architecture of Sensors. Hardware - Sensor Nodes Sensing: sensor --a transducer that converts a physical, chemical, or biological parameter into.
Real-Time Operating Systems RTOS For Embedded systems.
1 Operating System Support for Mobile Devices 4/5/2004 Richard Yang.
INTRODUCTION TO WIRELESS SENSOR NETWORKS
Chapter 4: Threads Modified by Dr. Neerja Mhaskar for CS 3SH3.
Overview Motivation (Kevin) Thermal issues (Kevin)
Real-time Software Design
Adaptive Mobile Applications
Module 12: I/O Systems I/O hardware Application I/O Interface
Jacob R. Lorch Microsoft Research
Simulation of Distributed Application and Protocols using TOSSIM
Credits: 3 CIE: 50 Marks SEE:100 Marks Lab: Embedded and IOT Lab
Mobile Systems Richard Yang.
Real-time Software Design
Introduction to Microprocessors and Microcontrollers
CSCI1600: Embedded and Real Time Software
CS294-1 Reading Aug 28, 2003 Jaein Jeong
Threads, SMP, and Microkernels
Operating System Concepts
CS703 - Advanced Operating Systems
Lecture Topics: 11/1 General Operating System Concepts Processes
Lecture 4- Threads, SMP, and Microkernels
Language Processors Application Domain – ideas concerning the behavior of a software. Execution Domain – Ideas implemented in Computer System. Semantic.
Chapter 2: Operating-System Structures
Chapter 13: I/O Systems I/O Hardware Application I/O Interface
Chapter 2: Operating-System Structures
Operating System Overview
COMP755 Advanced Operating Systems
CSCI1600: Embedded and Real Time Software
Module 12: I/O Systems I/O hardwared Application I/O Interface
Presentation transcript:

1 Mobile Systems Richard Yang

2 Admin. r Homework 4 m due Friday Dec. 8th

3 Recap: J2ME and Windows CE/Mobile r Scale down a popular programming environment to ease learning r Use virtual machines to mask (some) device heterogeneity r Use versioning to avoid using lowest common denominator

4 TinyOS

5 Hardware r Assembled from off-the-shelf components r 4Mhz, 8bit MCU (ATMEL) m 512 bytes RAM, 8KB ROM r Devices m 900Mhz Radio (RF monolithics) ft. range m temperature sensor & light sensor m LED outputs m serial Port 1.5” x 1.5”

6 Schematic Diagram of a Mote

7 Sample Applications r Active-badge-like location detection r Sensor network monitoring m periodically transmit node measurements to a base station m forward data for other nodes that are out of range of the base station m dynamically determine the correct routing topology for the network

8 Requirements r Small foot print m devices have limited memory and power resources r Easy integration of hardware and software components m think of a software component as a synthetic hardware components simulating the behavior of advanced hardware r Many other requirements, e.g., m robust operation should be reliable, and assist applications in surviving individual device failures

9 Example Application r A simple TinyOS application which periodically reads in the light intensity value, computes a moving average, displays it on the LED How would you develop the system?

10 TinyOS: Components r A tinyOS consists of one or more components linked together m software components motivated by hardware component r Each component specifies that m it provides some interfaces allows other components to control it m also uses some interfaces control other components

11 Interface r An interface m declares a set of functions called commands that provider must implement and m another set of functions called events that the interface user must implement A uses interfaces I1 and I2 B provides I1 C provides I2 commands events commands events I1 I2 C provides I3

12 Interface: Examples StdControl.nc interface StdControl { command result_t init(); command result_t start(); command result_t stop(); } Timer.nc interface Timer { command result_t start( char type, uint32_t interval); command result_t stop(); event result_t fired(); } ADC.nc interface ADC { async command result_t getdata(); async command result_t getContinuousData(); event result_t dataReady(uint 16_t data); }

13 Linking Components Two types of components: m modules: individual components m configurations : assemble components together, connecting interfaces (objects) used by components to interfaces (objects) provided by others

14 Example Application r A simple TinyOS application which periodically reads in the light intensity value, computes a moving average, displays it on the LED See SenseTaskM.nc SenseTask.nc

15 TinyOS Component: Implementation r Component contains: m commands and event handlers can invoke lower level commands, but cannot block event handler can signal higher level signals while command cannot m frame (storage) statically allocated, fixed sized to know memory requirement and avoid overhead of dynamic allocation Component Internal State Internal Tasks CommandsEvents

16 TinyOS Execution Model r Concurrency model: only two threads m long running tasks that can be interrupted by hardware event handlers r Tasks perform the primary computation work m commands and event handlers post tasks m call lower level commands m signal higher level events m schedule other tasks within a component r Each task is atomic with respect to other tasks m run to completion, but can be preempted by events m the task scheduler is a simple FIFO scheduler

17 Running tinyOS Program r make mica r ncc -o main.exe -target=mica SenseTask.nc r avr-objcopy --output-target=srec main.exe main.srec r Use uisp to install

18 A More Complete Sample Application r Sensor network monitoring m monitor temperature and light conditions m periodically transmit measurements to a base station m sensors can forward data for other sensors that are out of range of the base station m dynamically determine the correct routing topology for the network

19 Internal Component Graph RFM Radio byte Radio Packet UART UART Packet I2C Temp Light Active Messages Clocks bit byte packet Ad hoc Routing Application application HW SW

20 Message Send Transition r Total propagation delay up the 5 layer radio communication stack is about 80 instructions Timing diagram of event propagation

21 Evaluation: Storage Component NameCode Size (bytes) Data Size (bytes) Routing AM_dispatch AM_temperature AM_light AM RADIO_packet RADIO_byte RFM Light Temp UART UART_packet I2C Processor_init TinyOS scheduler C runtime Total  Scheduler only occupies 178 bytes  Complete application only requires 3 KB of instruction memory and 226 bytes of data (less than 50% of the 512 bytes available)  Only processor_init, TinyOS scheduler, and C runtime are required

22 Evaluation: Timing OperationsCost (cycles) Time (µs) Normalized to byte copy Byte copy821 Post an Event Call a Command Post a task to scheduler Context switch overhead Interrupt (hardware cost) Interrupt (software cost)

23 Mobile CPU Scheduling

24 Discussion r What does CPU scheduling do in a traditional operating system? r What (new) problems does CPU scheduling face in mobile computing?

25 CPU Power Consumption r A major challenge of mobile CPU scheduling is to reduce power consumption m CPU consumes 10%-30% of notebook power r The power consumption rate P of a CMOS processor satisfies where k is a constant, C the capacitance of the circuit, f the CPU frequency, and V the voltage

26 CPU Power Consumption r When the supply voltage is lower, charging/discharging time is longer; thus frequency should be lower r Thus power consumption ~ O(V 3 ) What does it imply?

27 Dynamic Voltage Scaling r Dynamic Voltage Scaling (DVS) allows voltage to be dynamically adjusted to save power r DVS-enabled processors, e.g., m AMD (PowerNow!) m Intel (SpeedStep, XScale) m Texas Instrument m Transmata r Discussion: what voltage to operate on? throughput

28 Dynamic Voltage Scaling r Basic idea: determining voltage according to program response time requirement r For normal applications, give reasonable response time r For multimedia applications, use the deadline to determine voltage

29 Architecture CPU monitoring scheduling speed scaling demand distribution scheduler speed adaptor profiler multimedia applications requirements time constraint

30 Demand Prediction  Online profiling and estimation: count number of cycles used by each job b 1 b 2 C min =b 0 b r =C max 1 b r-1 cumulative probability CDF F(x) = P [X  x]

31 Observations Demand distribution is stable or changes slowly

32 CPU Resource Allocation How many cycles to allocate to a multimedia job? Application should meet  percent of deadlines  each job meets deadline with probability   allocate C cycles, such that F (C ) =P [X  C ]   b 1 b 2 b 0 brbr 1 b r-1 cumulative probability F(x)F(x)  C

33 How Fast to Run the CPU?  Assume the strategy is to run job i at a fix (also called uniform) speed S i  Assume it needs C i cycles during a time duration of P i  Fact: since power is a convex function of frequency, if a job needs C cycles in a period P, then the optimal frequency is C/P, namely the lowest constant frequency.

34 Why Not Uniform Speed? Intuitively, uniform speed achieves - minimum energy if use the allocated exactly However, jobs use cycles statistically - often complete before using up the allocated - potential to save more energy  stochastic DVS

35 Stochastic DVS For each job 1.find speed S x for each allocated cycle x  time is 1/S x and energy is (1 - F(x))S 3 x such that

36 Example Speed Schedule 100 MHz200 MHz400 MHz cycle: speed: Job x10 6 cycles speed (MHz) Job x10 6 cycles Observation: speed up the processor with increasing clock cycles

37 DVS speed A1 B1 A1 execution speed up within job context switch 1.Store speed for switched-out 2.New speed for switched-in switch back A2

38 Implementation Hardware: HP N5470 laptop –Athlon CPU (300, 500, 600, 700, 800, 1000MHz)  round speed schedule to upper bound process control block standard Linux scheduler DVS modules PowerNow speed scaling Soft real-time scheduling system call Extension to Linux kernel lines of C code

39 Reduces power consumption However, limited due to few speed options Evaluation: Normalized Energy

40 Mobile File Systems

41 Discussion r What challenges does the file system face in wireless/mobile environment?

42 The Problems Caused by Mobility r Read miss m stalls progress (the user has to stop working) r Synchronization/consistency issues m may need to synchronize multiple copies of the same file m if multiple users, may need to solve consistency problems r Heterogeneous device types m each device has its own file systems and naming convention, e.g., digital camera, ipod

43 Approaches r Read miss m explicit user file selection, m automatic hoarding, e.g., CODA, SEER r Synchronization/consistency issues m keep modification logs and develop merge tools, e.g., Bayou m efficient file comparisons and merging, e.g., rsync, LBFS r Heterogeneous device types m masks the differences, e.g., EnsemBlue

44 SEER: automatic prediction of related files to avoid user manual configuration of hoarding

45 SEER: A Predictive Hoarding System r Views user activities as composed of projects than individual files r Predicates files in a project and fetch them together r Discussion: how do you predicate all of the files a project may use?

46 Basic Idea of SEER: Semantic Distance r Quantifies user’s intuition about relationship between files m smaller  closer in relation r Infers relationship m static (d one by an external investigator ), e.g., observes directory structure/membership observes naming convention #include in a program m dynamic watches user’s behavior

47 Lifetime Semantic Distance r Looks at file open/close (not file content !!) r Lifetime semantic distance: The lifetime semantic distance between an open of file A and an open of file B is defined as 0 if A has not been closed before B is opened and the number of intervening file opens (including the open of B) otherwise r End up with multiple lifetime semantic distances between two events of two files m needs distance between two files, not events m uses geometric mean to convert to a single distance A B C D Time Sample file access sequence Semantic distance - A  B, A  C is 0 - A  D is 3

48 Basic Idea of SEER: Clustering Algorithm r Based on algorithm by Jarvis and Patrick r Allows overlapping clusters r Steps m calculates n nearest neighbors for each file  Phase 1: if two points (files here) have at least kn overlapping neighbors, combine their clusters into one  Phase 2: if two points have more than kf but less than kn overlapping neighbors, overlap the clusters i.e. add each to the other cluster RelationAction kn ≤x kf≤x<k n x<kf Combine clusters Overlapping clusters No action Summary of clustering algorithm

49 Example r Seven files, A-G {A} {B} {C} {D} {E} {F} {G} r Phase 1: {A, B}  {A, B, C} {D, E} {F, G}  {D,E,F, G} r Phase 2: two pairs {A, C} {C, D} {A, C} : same cluster already {C, D}  overlap clusters r Final result {A, B, C, D} {C,D, E, F,G} Number of shared neighbors FromTo A B C D E F G ABCDEFGABCDEFG kn kf kn kf kn

50 Using Both Lifetime Semantic Distance and the Input of External Investigator r Essentially gives application specific info r Example m large directory distance => looser relationship subtract directory distance from shared neighbor count

51 Real World Anomalies: Special Cases r Many special cases m authors use a heuristic to solve each r Shared libraries m e.g. : library X m might cause unwanted clustering m Heuristic: files which represent more than a certain percentage of all references marked as “frequently-referenced” (1%) eliminate from calculation

52 r Critical files (e.g. : startup files) m rarely accessed but important m use heuristic and hoard special control file that specifies such files detect by names e.g..login etc r Temporary files (e.g. : in /tmp) m transient and don’t depict correct relationship m might displace other important files from n closest m heuristic: ignore files in /tmp etc. completely r Simultaneous access m e.g. : read mail & compile code m independent streams are intermixed ! m maintain reference-history on a per-process basis More Special Cases …

53 Scheduling of Multimedia Applications  Earliest deadline first (EDF) scheduling  - allocate cycle budget per job  - execute job with earliest deadline and positive budget  - charge budget by number of cycles consumed  - preempt if budget is exhausted

54 Bayou: automatic conflict update

55 Bayou: Managing Update Conflicts r Basic idea: application specific conflict detection and update r Two mechanisms for automatic conflict detection and resolution m dependency check m merge procedure

56 Bayou Write Operation: An Example

57 Mobile file systems: dealing with low bandwidth: LBFS: efficient file comparison and merging

58 Motivation r The CODA system assumes that modifications are kept as logs (CML) m a user sends the logs to the servers to update r If the storage of a client is limited, it may not be able to save logs m then upon reconnection, the cache manager needs to find the difference between the stored file and its local cached copy  same problem exists for the rsync tool ! r Question: how to efficiently compare the differences of two remote files (when the network connection is slow)?

59 LBFS: Low-Bandwidth File System r Break Files into chunks and transfer only modified chunks r Fixed chunk size does not work well m why?

60 Flexible Chunk Size r Compute hash value of every 48 byte block m if the hash value equals to a magic value, it is a chunk boundary