1. 1 Mobile Systems Richard Yang

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

3. 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. 4 TinyOS http://www.tinyos.net/tinyos-1.x/doc/tutorial/

5. 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) 10-100 ft. range m temperature sensor & light sensor m LED outputs m serial Port 1.5” x 1.5”

6. 6 Schematic Diagram of a Mote

7. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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 88 40 78 146 356 334 810 310 84 64 196 314 198 0 32 8 40 8 1 40 8 Processor_init TinyOS scheduler C runtime 172 178 82 30 16 0 Total3450226  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. 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 10 46 51 2.5 11.5 12.75 1.25 6 Interrupt (hardware cost)92.251 Interrupt (software cost)7117.759

23. 23 Mobile CPU Scheduling

24. 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. 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. 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. 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!) http://www.amd.com/us-en/assets/content_type/DownloadableAssets/Power_Now2.pdf m Intel (SpeedStep, XScale) m Texas Instrument m Transmata r Discussion: what voltage to operate on? throughput

28. 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. 29 Architecture CPU monitoring scheduling speed scaling demand distribution scheduler speed adaptor profiler multimedia applications requirements time constraint

30. 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. 31 Observations Demand distribution is stable or changes slowly

32. 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. 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. 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. 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. 36 Example Speed Schedule 100 MHz200 MHz400 MHz cycle: speed: Job 1 2.5 x10 6 cycles speed (MHz) 100 400 200 Job 2 1.2 x10 6 cycles Observation: speed up the processor with increasing clock cycles

37. 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. 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 2.4.18 716 lines of C code

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

40. 40 Mobile File Systems

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

42. 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. 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. 44 SEER: automatic prediction of related files to avoid user manual configuration of hoarding

45. 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. 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. 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. 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. 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. 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. 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. 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. 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. 54 Bayou: automatic conflict update

55. 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. 56 Bayou Write Operation: An Example

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

58. 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. 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. 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