Ongoing Research Architecture and Realtime Laboratory

1
Ongoing ResearchArchitecture and Real-time
Laboratory
2
Current Areas of Research

• Emulation and simulation of large-scale real-time
  distributed systems
• Power- and temperature-aware computing
• Network processor fault-tolerance
• Nanotechnology fault-tolerance
• Sensor networks

3
Distributed Collaborative Adaptive Sensing (DCAS)
System

• Large number of radars
• Radars can operate collaboratively
• Radar settings must adapt to prevailing weather
  conditions.
• Radars can rapidly reconfigure in response to
  changing weather conditions
• Answer the needs of the end-users in a
  near-optimal way

4
Objectives

• Monitoring
• Monitor the behavior and health of the real
  system
• Provide a comprehensive graphical interface
• Integration and Testing
• Integrate and test the software for its
  interoperability
• Validation
• Demonstrate the correct operation of system
  components
• Experimentation
• Answer various what-if questions

5
DCAS Emulator

• Real software runs on a hardware platform
  identical to the operational hardware
• No modifications are required to the software
  when it is running on the emulator
• Radar data is generated offline and streamed to
  the systems control center in
• real time
• Several weather scenarios are available for
  experimentation
• RAPIDS provides a powerful interface to carry out
  experiments on the emulator

Central Data Store
System Control Center
RAPIDS monitoring probes
Network Emulation
NEM

User Input Control
Node 1
Node 2
Node N
GbE
RAPIDS Proxy Server
Radar Data Store
Radar Emulator
Radars
(runs offline)
RAPIDS Clients
6
RAPIDS Monitoring and Control Software Suite

• Monitoring of system performance
• Significant control over the system
• Automatic start-up/shut-down of processes in
  experiments
• Dynamic modification of monitoring parameters
• Visualization of collected events and metrics
• Remote operation users can connect remotely to
• Operational testbed to monitor current
  developments
• Emulator to run/watch experiments
• Complete logging and playback
• Simulation of realistic network conditions

7
Ongoing Work

• End-users training
• Demonstrate DCAS system principles and
  operational concepts to the end-users
• Emergency managers, forecasters, researchers
• Simulation of a large number of nodes
• How will the system scale up?
• Fault tolerance
• How will the system react to various failures?
• Is the recovery management effective enough?

8
Temperature Aware Floorplanning

• Idea
• utilize lateral heat diffusion to reduce peak
  temperature of the chip
• The larger the temperature difference, the larger
  the heat diffusion
• Beneficial to place hot blocks adjacent to cold
  blocks
• Results
• Maximum temperature reduction of 21oC while
  keeping a comparable wire length for Alpha
  processor
• 6.3oC reduction in maximum temperature for
  Pentium Pro with a penalty of 13 in wire length

Hotter
Cold
Hotter
Cold
Colder
Hot
Colder
Hot
9
Block Temperatures for gcc Benchmark
64.7?C
120?C
L2cache43?C
Steady-state temperature calculated using HotSpot
2.0 (UVa)
10
Modified Floorplan Wire-temp
Short wirelength low maximum temperature Reduct
ion in MaxTemp 21.1oC Increase in Wirelength
0.67 Ca.3, Cw.4, Ct.3 Small spread of
temperature 19.9?C
79.0?C
11
Fast Thermal Simulation TILTS

• Time Invariant Linear Thermal System (TILTS)
• CPU thermal system is a linear system.
• Formula
• Precompute A and B to save computations.
• Results
• 1300x speedup for ?t 100 us than the HotSpot
  simulator
• TILTS does not incur any accuracy loss compared
  to the HotSpot simulator

12
Temptor Lightweight Runtime Temperature
Monitoring

• Power modeling based on power-relevant events
  using performance counters inside microprocessors
• Use thermal simulator to calculate temperature
• Small overhead due to fast TILTS algorithm

Perfctr Device Driver
Pentium 4 CPU
Performance Counters
Empirical Power Equations
Power Vector
Temperature Distributions
HotSpot Thermal Model With TILTS
13
Temptor Observation Dyanmic thermal profile for
applications, gcc benchmark
Temperature (C)
Time (second)
14
Fetch Throttling Techniques

• Hardware-based techniques
• (DEP, JIT)
• Use dynamic run-time information.
• Use past behavior to predict future behavior.
• Cannot catch irregular situations such as abrupt
  program phase changes.
• Might cause substantial performance degradation.

• Software-based techniques
• (CFT)
• Estimate ILP based on compile-time program
  analysis.
• Use fixed low IPC threshold for throttling - to
  avoid high performance loss.
• Cannot capture dynamic effects, such as cache
  misses.
• Energy savings is small for low IPC threshold.

15
CAFT Compiler-based Adaptive Fetch Throttling

• CAFT combines the benefits of software- and
  hardware-only fetch throttling techniques.
• After decoding, we know the estimated IPC - how
  many instructions are likely to be issued in the
  next cycle( compiler-based IPC estimation).
• We also know the Decode/Issue Difference (DID)
  value in this cycle.
• If estimated IPC of next cycle is less than the
  DID value, throttling will still leave enough
  instructions in the IQ.
• DID is used as recent history information to
  change the IPC threshold adaptively.

16
CAFT Execution Time and Energy

• CAFT keeps the advantage of low performance
  penalty of CFT, and has high energy savings as
  hardware-based techniques.

17
Other Areas

• Sensor networks Resource management of
  large-scale networks.
• Nanotechnology Fault-tolerant structures for
  nanotube/nanowire-based technologies.

18
Participants

• Anna Bekkerman
• Yongkui Han
• Nauman Javed
• Israel Koren
• C M Krishna
• Vijay Lakamraju
• Srikanth Sundaresan
• Huaping Wang
• Yizheng Wang