1 Operating System Support for Mobile Devices 4/5/2004 Richard Yang

2 Outline r Admin. and recap r CPU scheduling r Operating systems for mobile devices

3 Admin. r Homework 1 r Homework 2 r Midterm r Homework 3 m on localization m due: 11:59PM April 12 r Project m please make an appointment with me and the TA so that we can have some detailed discussions

4 Project Proposals r Increasing Connectivity through Controlled Mobility James Terry and Mike Bell r Using Mobility for Localization and Coverage Ana Cerejo, John Corwin, and Diego Montenegro r Controlled Mobility: Mobile Beacons For Clock Synchronization Ashish Vatsal and Gregory Edwards r Optimizing Clock Synchronization in Mobile Networks Hang Cheng, Tomislav Nad, and Mirtcho Spassov r Controlled Mobility for Multicast Ashley Green and Brad Rosen r Dynamic Boundary Estimation Using Mobile Sensor Networks Dimitrios Lymberopoulos, Jia Fang, and Akin Babayigit

5 Project Proposals (cont’) r Wireless Communication and Localization in Rapidly Changing Real-time Environments with Air-Plane Trainers Johnny Yeh and Praneeth Wanigasekera r Prevent Source-cheating in Incentive Compatible Routing in Wireless Ad-Hoc Networks Hao Wang and Yinghua Wu r Security against DOS attacks in Wireless Ad-Hoc Networks Andrew Park and Bobby Vellanki r Improving SEER Through Generalized Learning Algorithms Reuben Grinberg and Joshua Barnard r DarkTooth: Anonymous H2H (Human to Human) File Transfer Over Non-cooperative, Untrusted Wireless Networks Anthony Young, Wesley Maness, and David Hughes

6 Recap: Mobile File Systems r Problems: give user file access while disconnected or weakly connected m read miss m delayed write r Solution m CODA hoarding: persistently store files in local caches m SEER automatic hoarding prediction m Bayou basic idea: application specific conflict detection and update

7 Outline r Admin. and recap  CPU scheduling r Operating systems for mobile devices

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

9 CPU Power Consumption r CPU consumes 30%-50% of notebook power r the power P of a CMOS processor satisfies where k is a constant, C the capacitance of the circuit, f the CPU frequency, V the voltage, and V t a threshold voltage r Thus power consumption ~ O(V 3 ) m a convex function of V (and/or f)

10 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

11 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

12 Architecture CPU monitoring scheduling speed scaling demand distribution Scheduler Speed Adaptor Profiler Multimedia Applications requirements time constraint

13 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]

14 Observations Demand distribution is stable or changes slowly

15 CPU Resource Allocation How many cycles to allocate to a multimedia job? Application requires  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

16 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

17 How Fast to Run the CPU?  Assume job i need C i cycles during P i period  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:

18 Why Not Uniform Speed? Intuitively, uniform speed - 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

19 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 2 x such that

20 Stochastic DVS r Approximate solution to the preceding optimization problem r Speed schedule m list of points (cycle bi, speed S bi ) m change speed to S bi at bi cycles

21 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

22 SRT + 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

23 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 SRT-DVS modules PowerNow speed scaling Soft real-time scheduling system call Extension to Linux kernel lines of C code

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

25 Outline r Admin. and recap r CPU scheduling r Operating systems  Windows CE for PDAs m TinyOS for devices with extremely limited resources

26 Windows CE/Pocket PC r Microsoft’s attempt for writing an operating system for mobile devices r Several versions m Pocket PC m Pocket PC Phone version m Smart phone version r A scaled down version of Windows m still provides most functionalities such as multithreading …

27.NET Compact Framework r Programming languages compile to MSIL m MSIL is JIT compiled on the device m MSIL code is smaller than native executables m MSIL allows your code to be processor independent. Important for Pocket PC developers because Pocket PC devices use many types of processors r The.NET CF is a subset of the full.NET framework with some additions m designed for resource constrained devices m 1,400 classes for.NET CF vs. 8,000 for full m 27 UI controls for.NET CF vs. 52 for full m 1.5 MB for.NET CF vs. 30 MB for full

28 Outline r Admin. and recap r CPU scheduling r Operating systems m Windows CE for PDAs  TinyOS for devices with extremely limited reosurces

29 Motivation r Devices such as sensors with extremely limited by resource m today, sensors exist on the scale of a square inch in size, and a fraction of a watt in power. m in the future, it may be possible to reduce sensors to the size of a cubic millimeter, or smaller r Objective m build an operating system for devices with extremely limited resources

30 Today’s Hardware r Assembled from off-the-shelf components r 4Mhz, 8bit MCU (ATMEL) m 512 bytes RAM, 8KB ROM r 900Mhz Radio (RF Monolithics) m ft. range r Temperature sensor & light sensor r LED outputs r Serial Port 1.5” x 1.5”

31 Operating System Requirements r Small foot print m devices have limited memory and power resources r Diversity in design and usage m provide a high degree of software modularity for application specific sensors r Concurrency intensive operation m need a simple concurrency model r Many other requirements, e.g., m Robust operation OS should be reliable, and assist applications in surviving individual device failures

32 TinyOS r A microthreaded OS that draws on previous work done for lightweight thread support, and efficient network interfaces r Developed at Berkeley

33 Important Concepts: First Step r TinyOS concepts are expressed in nesC, a C-like language r Concurrency model: a two level scheduling structure m Long running tasks that can be interrupted by hardware event handlers r Component model: specification m A tinyOS consists of one or more components linked together m Each component provides and uses interfaces m An interface declares a set of functions called commands that provider must implement and another set of functions called events that the interface user must implement r Component: implementation m two types of components: modules and configurations m modules: provide application code, implementing one or more interface m configurations: assemble other components together, connecting interfaces used by components to interfaces provided by others

34 Example: Blink r A simple TinyOS application which causes the red LED on a mote to turn on and off at 1Hz

35 Example: Blink Blink.nc configuration Blink { } implementation { components Main, BlinkM, SingleTimer, LedsC; Main.StdControl -> BlinkM.StdControl; Main.StdControl -> SingleTimer.StdControl; BlinkM.Timer -> SingleTimer.Timer; BlinkM.Leds -> LedsC; }

36 The StdControl Interface StdControl.nc interface StdControl { command result_t init(); command result_t start(); command result_t stop(); }

37 The BlinkM Module BlinkM.nc module BlinkM { provides { interface StdControl; } uses { interface Timer; interface Leds; } implementation { command result_t StdControl.init() { call Leds.init(); return SUCCESS; } command result_t StdControl.start() { return call Timer.start(TIMER_REPEAT, 1000) } command result_t StdControl.stop() { return call Timer.stop(); } event result_t Timer.fired() { call Leds.redToggle(); return SUCCESS; } Timer.nc interface Timer { command result_t start( char type, uint32_t interval); command result_t stop(); event result_t fired(); }

38 Running the Program r make mica r ncc -o main.exe -target=mica Blink.nc r avr-objcopy --output-target=srec main.exe main.srec r Use uisp to install