CSC 714 Projects


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • unenforceable: later tasks can override settings silently, no facility to guarantee isolation ‘ as expected’: only changeable when IRQ is pending, so hardly ever. useful guarantees: guarantees in the 10’s of milliseconds may be feasible. PCI latencies measured worst case around 10us. 36 is calculated worst case.
  • hot-plug supported on some linux platforms, only per chip not per core. Linux changes required: enforce task cpu, allow scheduler per cpu set, early IRQ mapping, etc Virtualization: do any existing systems allow hardware partitioning like this? Latency Timer: PCI spec allows writing of max bus hold timer per device: Latency vs efficiency
  • CSC 714 Projects

    1. 1. CSC 714 Projects Spring 2009
    2. 2. P1: Pull Based Migration of Real-Time Tasks in Multi-Core Processors <ul><li>Real-Time Scheduling on Multi-processors </li></ul><ul><ul><li>Practical Schedulers </li></ul></ul><ul><ul><ul><li>Dynamic assignment of tasks to multi-cores </li></ul></ul></ul><ul><ul><ul><li>Fundamental Premise: tasks can migrate </li></ul></ul></ul><ul><li>Problem </li></ul><ul><ul><li>Task Migration causes cold cache misses </li></ul></ul><ul><li>Temporal Guarantee in wake of Task Migration </li></ul>Task Migration
    3. 3. Solution <ul><li>Scheduler has knowledge of </li></ul><ul><ul><li>Task to migrate </li></ul></ul><ul><ul><li>Source and Target Cores </li></ul></ul><ul><li>Developer knows the critical memory regions </li></ul><ul><ul><li>Combine the two into a prefetch thread </li></ul></ul><ul><li>Working </li></ul><ul><ul><li>Scheduler spawns prefetch thread at target </li></ul></ul><ul><ul><ul><li>Prefetch thread has lowest priority </li></ul></ul></ul><ul><ul><li>Overlap prefetching with slack before next invocation </li></ul></ul>
    4. 4. Simulation Results <ul><li>Matmult: </li></ul><ul><ul><li>minor impact of task migration </li></ul></ul><ul><ul><li>Algorithmic complexity O(n 3 ) </li></ul></ul><ul><li>CRC </li></ul><ul><ul><li>Prefetch thread does not fill </li></ul></ul><ul><ul><li>L1 I$ </li></ul></ul><ul><ul><li>L1 Cache I$ misses significant </li></ul></ul><ul><li>CRC </li></ul><ul><ul><li>Scattered Critical Regions </li></ul></ul><ul><ul><li>Additional prefetch function calls </li></ul></ul><ul><li>Inferences </li></ul><ul><li>Cold Cache Misses can be hidden with prefetch scheme: Tighter bounds </li></ul><ul><li>Future Work: Memory layout may improve predicting the prefetch thread overhead </li></ul>
    5. 5. P2: Security Techniques in Cyber-Physical Systems <ul><li>Real-Time Systems Lack </li></ul><ul><ul><li>Resources </li></ul></ul><ul><ul><li>Complex OS </li></ul></ul><ul><li>Failures can </li></ul><ul><ul><li>Effect Environment </li></ul></ul><ul><ul><li>Effect Infrastructure </li></ul></ul><ul><ul><li>Harm Life </li></ul></ul>
    6. 6. Real-Time Security Features <ul><li>Static Timing Analysis provides </li></ul><ul><ul><li>WCET </li></ul></ul><ul><ul><li>BCET </li></ul></ul><ul><li>Predictable Scheduler Interupts </li></ul><ul><ul><li>Check in on jobs </li></ul></ul><ul><li>Use timing data to bound regions of the running jobs </li></ul><ul><ul><li>In Application </li></ul></ul><ul><ul><li>In Scheduler </li></ul></ul>
    7. 7. Experiment <ul><li>Extend Current Research </li></ul><ul><ul><li>Periodic Scheduler and Program Instrumentation </li></ul></ul><ul><ul><ul><li>Wide Granularity Checkpoints Fixed Distance </li></ul></ul></ul><ul><ul><li>Periodic Scheduler Orthogonal to Program </li></ul></ul><ul><ul><ul><li>Arbitrary PC wakeup values must insure appropriate pessimism </li></ul></ul></ul>
    8. 8. P3: Android Adhoc Wifi Networking <ul><li>Ad-hoc networking between G1 Android phones </li></ul><ul><li>Social networking application </li></ul><ul><ul><li>Text messages </li></ul></ul><ul><ul><li>Status updates </li></ul></ul><ul><ul><li>GPS coordinates </li></ul></ul>
    9. 9. Solution: Adhoc Client Application <ul><li>Borrow from Wifi-Tether Open Source project </li></ul><ul><ul><li>Init files, iptables, dnsmasq, tether script </li></ul></ul><ul><li>Discovery of other Ad-hoc endpoints </li></ul><ul><ul><li>WifiManager not available </li></ul></ul><ul><ul><li>Alternate between DHCP Server/Client </li></ul></ul><ul><ul><li>UDP broadcast heartbeat messages </li></ul></ul><ul><li>Threads </li></ul><ul><ul><li>UDP sender, UDP receiver, network control </li></ul></ul><ul><li>GUI Screens </li></ul><ul><ul><li>Settings, Incoming Events, Friend List, My Status, Message View </li></ul></ul><ul><li>Tester program (runs on Laptop) </li></ul><ul><ul><li>Echos back status message, GPS coordinates </li></ul></ul>
    10. 10. Results <ul><li>Successfully connected 2 phones in Ad-hoc mode </li></ul><ul><ul><li>DHCP Server/ Client </li></ul></ul><ul><li>Also included an Access Point mode </li></ul><ul><li>Laptop tester: </li></ul>
    11. 11. P4: CPU Shielding: Basics <ul><li>Multi-core/Multi-processor Systems </li></ul><ul><li>Start with standard Linux </li></ul><ul><li>Partition CPUs between normal and RT </li></ul><ul><li>Force all standard work to normal CPUS </li></ul><ul><li>Use existing IRQ and Task affinities </li></ul><ul><li>Project purpose: Demonstrate feasibility </li></ul>
    12. 12. CPU Shielding: Results <ul><li>Task affinities work, but are unenforceable </li></ul><ul><li>IRQ affinities don’t work as expected </li></ul><ul><li>Several IRQs must be per-CPU (ex. Local timer, TLB helper) </li></ul><ul><li>Without kernel changes no useful guarantees are possible </li></ul><ul><li>With kernel changes PCI bus speed becomes the concern (single PCI port write takes up to 36 ㎲ on lab systems). </li></ul>
    13. 13. CPU Shielding: Future <ul><li>Look at hiding CPUs & hardware via hot-plug system </li></ul><ul><li>Kernel driver & structural changes to implement scheduler for “off-line” CPUs </li></ul><ul><li>Not a simple change. Worthwhile? </li></ul><ul><ul><ul><li>Security & Reliability of dual systems </li></ul></ul></ul><ul><ul><ul><li>Easier to implement using existing virtualization methods? </li></ul></ul></ul><ul><li>Limiting PCI latencies via ‘Latency Timer’ </li></ul>
    14. 14. P5: Preemption Threshold aware Task-Scheduling Simulator Term Project CSC714, April 2009 Sangyeol Kang, Kinjal Bhavsar
    15. 15. <ul><li>Needs in design time </li></ul><ul><ul><li>To help simulation of trial schedules </li></ul></ul><ul><ul><li>To support preemption threshold scheduling </li></ul></ul><ul><li>Implementation of timing simulator </li></ul><ul><ul><li>RM, DM, EDF </li></ul></ul><ul><ul><li>Preemptive/Non Preemptive </li></ul></ul><ul><li>Supporting Preemption Threshold Scheduling </li></ul><ul><ul><li>For fixed priority scheduling </li></ul></ul><ul><ul><li>Computing appropriate PT values using MPTA algorithm </li></ul></ul><ul><ul><li>Preempt only when “priority > PT of current running task” </li></ul></ul><ul><li>Graphical representation of simulated scheduling </li></ul><ul><ul><li>By using third-party tool (gnuplot) </li></ul></ul>Motivation / Objectives
    16. 16. Results Simulation Statistics Graphical Representation Task set & Parameters
    17. 17. P6: Fault Tolerant Algorithm for Multi Hop Wireless Sensor Networks <ul><li>Features </li></ul><ul><ul><li>Rerouting capability on failure </li></ul></ul><ul><ul><li>Fault Tolerance through hardware redundancy </li></ul></ul><ul><ul><li>Isolation and self-recovery </li></ul></ul><ul><ul><li>Supports mobile sensor networks </li></ul></ul><ul><ul><li>Deployment of data mule to fetch/bridge isolated nodes. </li></ul></ul><ul><li>Built using Contiki OS and LNPD </li></ul><ul><ul><li>Used Reliable Unicast protocol in Rime communication stack of Contiki to mote-mote communicate </li></ul></ul><ul><ul><li>Used periodic broadcast for dynamic ad-hoc network formation. </li></ul></ul><ul><ul><li>LNPD is used for directing RCX data mule to bridge nodes </li></ul></ul><ul><ul><li>Used serial communication from mote to PC for instructing RCX </li></ul></ul>
    18. 18. 1 2 3 2 3 3 1 3
    19. 19. Open Issues and Improvements <ul><ul><li>Implementing the multi coordinator network </li></ul></ul><ul><ul><li>Capability to place nodes using RCX </li></ul></ul><ul><ul><li>The rover should be more sophisticated </li></ul></ul><ul><ul><li>Investigate feasibility of implementation using TCP/IP stack in Contiki </li></ul></ul>
    20. 20. P7: Service Time Overlay for Google Maps Karthikeyan Sivaraj Mansoor Aftab
    21. 21. <ul><li>An application to report average service times (waiting time) </li></ul><ul><li>Users may like to know waiting times for banks, restaurants etc. beforehand </li></ul><ul><ul><li>Helps user plan schedule better </li></ul></ul><ul><li>Accessible on a custom Google Maps overlay </li></ul><ul><ul><li>User can navigate to the desired location and click to know </li></ul></ul><ul><li>Data for service times is collected from the users phone </li></ul>Introduction
    22. 22. <ul><li>We use the Location(GPS) API provided in the Android SDK </li></ul><ul><li>Client component implemented on user phones </li></ul><ul><ul><li>A background service reports location changes to server every minute </li></ul></ul><ul><ul><li>Sends UDP messages with location and time spent </li></ul></ul><ul><ul><li>MapView component to access service times </li></ul></ul><ul><li>Server component maintains database of locations and corresponding service times </li></ul><ul><ul><li>Implements various rules to decide validity of received data </li></ul></ul><ul><ul><li>Responds to queries from the MapView component </li></ul></ul>Implementation
    23. 23. <ul><li>Successfully implemented/tested the application with a distance resolution of 20m </li></ul><ul><li>Provided user option to enable/disable background service </li></ul>Results
    24. 24. P8: Save Gas Map <ul><li>Problem description </li></ul><ul><li>To identify the shortest path for a given set of addresses and display them on the map </li></ul>Team Members: Raghuveer Raghavendra Prasanna Jeevan
    25. 25. Implementation details <ul><li>Features </li></ul><ul><li>Takes Input of multiple locations </li></ul><ul><li>Finds the shortest distance between all the locations (Using a heuristic algorithm for TSP) </li></ul><ul><li>Arranges the locations into a optimal route </li></ul><ul><li>Displays the location on Google map </li></ul><ul><li>Major classes used are Android Location, Maps and Overlay </li></ul>
    26. 26. Snapshots
    27. 27. <ul><li>Description: Design a PACMAN game using Lego-bots. </li></ul><ul><li>Motivation: Design a simple system from scratch to study the interactions between the different units and design and timing complexities that are encountered. </li></ul><ul><li>Aim: Pacman should traverse the entire maze while staying out of enemy’s way </li></ul>P9:
    28. 28. <ul><ul><li>PACBOT and EnemyBots = line-followers + Messaging unit + Path-decision Logic </li></ul></ul><ul><ul><li>Central Control = IR tower + messaging unit + display </li></ul></ul><ul><li>Issues: </li></ul><ul><ul><li>Working of LNPD/Message setup </li></ul></ul><ul><ul><li>Path-decision algorithm </li></ul></ul><ul><ul><li>Timing </li></ul></ul><ul><ul><li>Orientation of RCX wrt the IR tower </li></ul></ul><ul><ul><li>Maze design </li></ul></ul>
    29. 29. <ul><li>Pacman needs to know enemy’s coordinates and direction </li></ul><ul><li>Adjusted weights used for choosing direction </li></ul><ul><li>Adjusted weight is a function of the numbers of untraversed cells in the direction and the presence/distance of enemy bots. </li></ul>
    30. 30. P10: Android Wifi Social Networking Sushmita Lokala Phil Marquis CSC714
    31. 31. Application <ul><li>Read from disk </li></ul><ul><li>Get location </li></ul><ul><li>Get wifi status </li></ul><ul><li>Send to server </li></ul><ul><li>Receive from server </li></ul><ul><li>Write to disk </li></ul><ul><li>Draw map </li></ul><ul><li>Draw overlays </li></ul>
    32. 32. Classes <ul><li>1. Wifi </li></ul><ul><li>WifiNetwork: SSID, Level </li></ul><ul><li>WifiData: Latitude, Longitude, WifiNetworks </li></ul><ul><li>WifiUserHistory: Name, WifiDatas </li></ul><ul><li>2. Maps </li></ul><ul><li>WifiOverlay </li></ul>
    33. 33. Classes <ul><li>3. Serialization: Disk </li></ul><ul><li>ObjectOutputStream </li></ul><ul><li>4. Serialization: Server </li></ul><ul><li>UDPServer </li></ul>
    34. 34. <ul><li>P11: A New Real-time Kernel development on an embedded platform </li></ul><ul><li>Team </li></ul><ul><li>BALASUBRAMANYA BHAT </li></ul><ul><li>SANDEEP BUDANUR RAMANNA </li></ul>CSC714: Real Time Systems Project – Spring 2009
    35. 35. Features <ul><li>A new real-time kernel developed from scratch </li></ul><ul><li>Supports Periodic & Aperiodic tasks, Semaphores & Mutex </li></ul><ul><li>EDF based scheduling for periodic tasks (deadlines <= period) </li></ul><ul><li>The scheduler is capable of creating tasks based on (  , p, e, D) parameters. </li></ul><ul><li>1 uSec granularity for all timing parameters (  , p, e, D) </li></ul><ul><li>Aperiodic tasks are scheduled using static priority based preemptive scheduling. </li></ul><ul><li>The scheduler can also keep track of the current CPU utilization. </li></ul>
    36. 36. Design Priority Queue based on the next DEADLINE Ready Q Wait Q I Aperiodic Q Priority Queue based on the next RELEASE Time Priority Queue based on task PRIORITY Timer 0 Res. Block Q Priority Queue based on Deadline / PRIORITY Resource Timer 1
    37. 37. Current Status <ul><li>Completed </li></ul><ul><li>Implemented on C6713 DSK </li></ul><ul><ul><li>TMS320C6713 DSP Processor </li></ul></ul><ul><ul><li>VLIW Architecture (with 8 instructions / cycle) </li></ul></ul><ul><li>Tested for all parameters (  , p, e, D) </li></ul><ul><li>Keeps track of Deadline miss & TBE counts for every thread </li></ul><ul><li>Also keeps track of thread wise execution time upto 1  s res. </li></ul><ul><li>About 2400 SLOCs of source code (1000 lines assembly) </li></ul><ul><li>Things to do </li></ul><ul><li>Overall CPU utilization to be maintained </li></ul><ul><li>Test aperiodic tasks with resources </li></ul><ul><li>Implement Sleep </li></ul><ul><li>Fix few bugs </li></ul><ul><li>Test with some real benchmarks </li></ul>
    38. 38. P12: MAC Protocol Implementation on Atmel AVR for Underwater Communication <ul><ul><ul><li>by Shaolin Peng </li></ul></ul></ul>CSC 714 Real Time Computer Systems
    39. 39. Aloha Protocol Atmega168 MACA Protocol Small & Sparse Network Small Packet Size Development Platform: STK500 AVR Studio
    40. 40. Problem List <ul><li>P1: Debugging Instrument </li></ul><ul><ul><li>Set up UART communication with the HyperTerminal on PC </li></ul></ul><ul><ul><li>Connect two boards using wire as a start </li></ul></ul><ul><li>P2: Starvation </li></ul><ul><ul><li>Wait only after sending, not after receiving </li></ul></ul><ul><li>P3: Flexible Length Packet Receiving </li></ul><ul><ul><li>Receive the first two bytes, decode and decide </li></ul></ul><ul><li>P4: CRC Consideration </li></ul><ul><ul><li>4 bits -> 8 bits ( x^ 8 + x^ 2 + x + 1) </li></ul></ul>
    41. 41. Problem List 2 <ul><li>P5: Random Number Generator </li></ul><ul><ul><li>ADC or Timer Counter </li></ul></ul><ul><li>P6: No response problem </li></ul><ul><ul><li>Set maximum r etr ies number </li></ul></ul><ul><li>P7: Hardware Limitation </li></ul><ul><ul><li>Compile different files using different optimization levels </li></ul></ul><ul><ul><ul><li>E.g. -O3 for Goertzel algorithm (critical path) </li></ul></ul></ul><ul><ul><ul><ul><ul><li>-Os for the other files </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><li>Text data bss total </li></ul></ul></ul></ul><ul><ul><ul><ul><li>14986 302 141 15429 (different optimization levels) </li></ul></ul></ul></ul><ul><ul><ul><ul><li>16380 338 109 16827 (same optimization level) </li></ul></ul></ul></ul>
    42. 42. Experimental Set u p Lake Raleigh Throughput= Successfully received packets Total packets sent out
    43. 43. Results <ul><li>Indoors </li></ul><ul><ul><li>Aloha: 27.2% </li></ul></ul><ul><ul><li>MACA: 23.8% </li></ul></ul><ul><li>Outdoors </li></ul><ul><ul><li>Aloha: 8.1% </li></ul></ul><ul><ul><li>MACA: 8.2% </li></ul></ul><ul><li>Compare with MACA </li></ul><ul><ul><li>During the testing time, Aloha received almost twice data than MACA </li></ul></ul>
    44. 44. P13: Power-Aware DVFS on PowerPC 405LP: Front Bus Scaling <ul><li>Mohamed Nishar Kamaruddin </li></ul><ul><li>Santhosh Selvaraj </li></ul><ul><li>OVERVIEW </li></ul><ul><li>Previous work with the IBM 405LP board showed that Feedback-DVS of the processor voltage and frequency produces considerable power savings. </li></ul><ul><li>Our work is to study the frequency scaling for the memory subsystem to achieve power savings. We also study the feasibility of integrating this with the existing feedback DVS-EDF scheduling schemes. </li></ul>
    45. 45. Development up to present <ul><li>Experimented with different operating points including those with same processor frequency but with different memory subsystem frequencies. This was done on a number of applications. </li></ul><ul><li>Changes to data acquisition programs and sample applications to record the power savings of the memory subsystem. </li></ul><ul><li>Integration of PLB frequency scaling into the various existing feedback DVS-EDF scheduling schemes. </li></ul>
    46. 46. Results <ul><li>Frequency scaling of the memory subsystem was found to produce significant power savings. Reducing the FSB freq from 100MHz to 50 MHz for a tight noop looped application produced nearly 34% energy savings. </li></ul><ul><li>Fitting this into the PID Feedback scheduling - we changed all operating points to use half of their original PLB frequencies. Energy savings now: 1.38%. </li></ul><ul><li>This is because the various operating points defined in the PID feedback scheduling code already scale PLB frequency along with processor frequency. </li></ul><ul><li>For memory intensive operation, energy savings: 1.1% </li></ul>