Programming Sensor Networks - PowerPoint PPT Presentation

Loading...

PPT – Programming Sensor Networks PowerPoint presentation | free to view - id: 214513-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Programming Sensor Networks

Description:

Gather temperature, humidity, light from a redwood tree ... need general programming: nodes in redwood trees don't need to locate snipers in Sonoma. ... – PowerPoint PPT presentation

Number of Views:26
Avg rating:3.0/5.0
Slides: 74
Provided by: Davi834
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Programming Sensor Networks


1
Programming Sensor Networks
David Gay Intel Research Berkeley
2
  • Object tracking
  • Sensors take magnetometer readings, locate object
    using centroid of readings
  • Communicate using geographic routing to base
    station
  • Robust against node and link failures

3
  • Environmental monitoring
  • Gather temperature, humidity, light from a
    redwood tree
  • Communicate using tree routing to base station
  • 33 nodes, 44 days

4
Challenges and Requirements
  • Expressivity
  • Many applications, many OS services, many
    hardware devices
  • Real-time requirements
  • Some time-critical tasks (sensor acquisition and
    radio timing)
  • Constant hardware evolution
  • Reliability
  • Apps run for months/years without human
    intervention
  • Extremely limited resources
  • Very low cost, size, and power consumption
  • Reprogrammability
  • Easy programming
  • used by non-CS-experts, e.g., scientists

5
Recurring Example
  • Multi-hop data collection
  • Motes form a spanning tree rooted at a base
    station node
  • Motes periodically sample one or more sensors
  • Motes perform some local processing, then send
    sensor data to parent in tree
  • Parents either process received data
    (aggregation) or forward it as is

6
Programming the Hard Way
C compiler
Assembler
7
The Real Programmers Scorecard
  • Expressivity
  • Real-time requirements
  • Constant hardware evolution
  • Reliability
  • Extremely limited resources
  • Reprogrammability
  • Easy programming

8
Programming the Hard Way
C compiler
Assembler
9
3 Practical Programming Systems
  • nesC
  • A C dialect designed to address sensor network
    challenges
  • Used to implement TinyOS, Maté, TinySQL (TinyDB)
  • Maté
  • An infrastructure for building virtual machines
  • Provide safe, efficient high-level programming
    environments
  • Several programming models simple scripts,
    Scheme, TinySQL
  • TinySQL
  • A sensor network query language
  • Simple, well-adapted to data-collection
    applications

10
nesC overview
  • Component-based C dialect
  • All cross-component interaction via interfaces
  • Connections specified at compile-time
  • Simple, non-blocking execution model
  • Tasks
  • Run-to-completion
  • Atomic with respect to each other
  • Interrupt handlers
  • Run-to-completion
  • Whole program
  • Reduced expressivity
  • No dynamic allocation
  • No function pointers

11
nesC component model
interface Init command bool init()
  • module AppM
  • provides interface Init
  • uses interface ADC
  • uses interface Timer
  • uses interface Send
  • implementation

A call to a command, such as bool ok call
Init.init() is a function-call to behaviour
provided by some component (e.g., AppM).
12
nesC component model
interface Init command bool init()
  • module AppM
  • provides interface Init
  • uses interface ADC
  • uses interface Timer
  • uses interface Send
  • implementation

interface ADC command void getData() event
void dataReady(int data)
Interfaces are bi-directional. AppM can call
ADC.getData and must implement event void
ADC.dataReady(int data) The component to
which ADC is connected will signal dataReady,
resulting in a function-call to ADC.dataReady in
AppM.
13
nesC component model
interface Init command bool init()
  • module AppM
  • provides interface Init
  • uses interface ADC
  • uses interface Timer
  • uses interface Send
  • implementation
  • TOS_Msg myMsg
  • int busy
  • event void ADC.dataReady()
  • call Send.send(myMsg)
  • busy TRUE
  • ...

interface ADC command void getData() event
void dataReady(int data)
interface Timer command void setRate(int
rate) event void fired()
interface Send command void send(TOS_Msg m)
event void sendDone()
14
nesC component model
configuration App implementation
components Main, AppM, TimerC, Photo,
MessageQueue
Main.Init -gt AppM.Init
AppM.Timer -gt TimerC.Timer
Main.Init -gt TimerC.Init
  • module AppM
  • provides interface Init
  • uses interface ADC
  • uses interface Timer
  • uses interface Send

Main
Init
Init
AppM
Timer
ADC
Send
Init
Timer
ADC
Send
TimerC
MessageQueue
Photo
15
Some Other Features
  • Parameterised interfaces, generic interfaces
  • interface ADCint id runtime dispatch between
    interfaces
  • interface Attributelttgt type parameter to
    interface
  • Generic components (allocated at compile-time)
  • Reusable components with arguments
  • generic module Queue(typedef t, int size)
  • Generic configurations can instantiate many
    components at once
  • Distributed identifier allocation
  • unique(some string) returns a different number
    at each use with the same string, from a
    contiguous sequence starting at 0
  • uniqueCount(some string) returns the number of
    uses of unique(some string)
  • Concurrency support
  • Atomic sections, compile-time data-race detection

16
nesC Scorecard
  • Expressivity
  • Subsystems radio stack, routing, timers,
    sensors, etc
  • Applications data collection, TinyDB, Nest final
    experiment, etc
  • Constant hardware evolution
  • René ? Mica ? Mica2 ? MicaZ Telos (x3)
  • Many other platforms at other institutions
  • How was this achieved?
  • The component model helps a lot, especially when
    used following particular patterns

17
nesC Scorecard
  • Expressivity
  • Subsystems radio stack, routing, timers,
    sensors, etc
  • Applications data collection, TinyDB, Nest final
    experiment, etc
  • Constant hardware evolution
  • René ? Mica ? Mica2 ? MicaZ Telos (x3)
  • Many other platforms at other institutions
  • How was this achieved?
  • The component model helps a lot, especially when
    used following particular patterns
  • Placeholder allow easy, application-wide
    selection of a particular service implementation
  • Adapter adapt an old component to a new interface

18
Placeholder allow easy, application-wide
selection of a particular service implementation
  • Motivation
  • services have multiple compatible implementations
  • routing ex MintRoute, ReliableRoute hardware
    independence layers
  • used in several parts of system, application
  • ex routing used in network management and data
    collection
  • most code should specify abstract service, not
    specific version
  • application selects implementation in one place

19
Placeholder allow easy, application-wide
selection of a particular service implementation
  • configuration Router
  • provides Init
  • provides Route
  • uses Init as XInit
  • uses Route as XRoute
  • implementation
  • Init XInit
  • Route XRoute

configuration App implementation
components Router, MRoute Router.XInit -gt
MRoute.Init Router.XRoute -gt MRoute.Route

20
Adapter adapt an old component to a new
interface
  • Motivation
  • functionality offered by a component with one
    interface needed needs to be accessed by another
    component via a different interface.

Light
AttrPhoto
TinyDB
ADC
Attribute
21
Adapter adapt an old component to a new
interface
  • generic module AdaptAdcC
  • (char name, typedef t)
  • provides Attributelttgt
  • provides Init
  • uses ADC
  • implementation
  • command void Init.init()
  • call Attribute.register(name)
  • command void Attribute.get()
  • call ADC.get()

configuration AttrPhoto provides
Attributeltlonggt implementation components
Light, new AdaptAdcC(Photo, long)
Attribute AdaptAdcC AdaptAdcC.ADC -gt Light
22
nesC scorecard
  • Expressivity
  • Constant hardware evolution
  • Real-time requirements (soft only)
  • Radio stack, especially earlier bit/byte radios
  • Time synchronisation
  • High-frequency sampling
  • Achieved through
  • Running a single application
  • Having full control over the OS (cf Placeholder)

23
nesC scorecard
  • Expressivity
  • Constant hardware evolution
  • Real-time requirements (soft only)
  • Reliability
  • C is an unsafe language
  • Concurrency is tricky
  • Addressed through
  • A static programming style, e.g., the Service
    Instance pattern
  • Compile-time checks such as data-race detection

24
Service Instance support multiple instances
with efficient collaboration
  • Motivation
  • multiple users need independent instance of
    service
  • ex timers, file descriptors
  • services instances need to coordinate, e.g., for
    efficiency
  • ex n timers sharing single underlying hardware
    timer

25
Service Instance support multiple instances
with efficient collaboration
  • module TimerP
  • provides Timerint id
  • uses Clock
  • implementation
  • timer_t timersuniqueCount(Timer)
  • command Timer.startint id()

generic configuration TimerC() provides
interface Timer implementation components
TimerP Timer TimerP.Timerunique(Timer)
components Radio, TimerC Radio.Timer gt new
TimerC()
26
Race condition example
  • module AppM
  • implementation
  • bool busy
  • async event void Timer.fired()
  • // Avoid concurrent data collection attempts!
  • if (!busy) // ? Concurrent state access
  • busy TRUE // ? Concurrent state access
  • call ADC.getData()

27
Data race detection
  • Every concurrent state access is a potential race
    condition
  • Concurrent state access
  • If object O is accessed in a function reachable
    from an interrupt entry point, then all accesses
    to O are potential race conditions
  • All concurrent state accesses must occur in
    atomic statements
  • Concurrent state access detection is
    straightforward
  • Call graph fully specified by configurations
  • Interrupt entry points are known
  • Data model is simple (variables only)

28
Data race fixed
  • module AppM
  • implementation
  • bool busy
  • async event void Timer.fired() // From
    interrupt
  • // Avoid concurrent data collection attempts!
  • bool localBusy
  • atomic
  • localBusy busy
  • busy TRUE
  • if (!localBusy)
  • call ADC.getData()

29
nesC scorecard
  • Expressivity
  • Constant hardware evolution
  • Real-time requirements (soft only)
  • Reliability
  • Extremely limited resources
  • Complex applications exist NEST FE, TinyScheme,
    TinyDB
  • Lifetimes of several months achieved
  • How?
  • Language features resolve wiring at
    compile-time
  • Compiler features inlining, dead-code
    elimination
  • And, of course, clever researchers and hackers

30
Resource Usage
  • An interpreter specialised for data-collection
  • Makes heavy use of components, patterns
  • Optimisation reduces power by 46, code size by
    44
  • A less component-intensive system (the radio)
    only gains 7 from optimisation

inlining dead-code dead-code only no optimisation
power draw 5.1mW 9.5mW 9.5mW
code size 47.1kB 52.5kB 83.8kB
31
nesC scorecard
  • Expressivity
  • Constant hardware evolution
  • Real-time requirements (soft only)
  • Reliability
  • Extremely limited resources
  • Reprogrammability
  • Whole program only
  • Provided by a TinyOS service

32
nesC scorecard
  • Expressivity
  • Constant hardware evolution
  • Real-time requirements (soft only)
  • Reliability
  • Extremely limited resources
  • Reprogrammability
  • Easy programming
  • Patterns help, but
  • Split-phase programming is painful
  • Distributed algorithms are hard
  • Little-to-no debugging support

33
3 Practical Programming Systems
  • nesC
  • A C dialect designed to address sensor network
    challenges
  • Used to implement TinyOS, Maté, TinySQL (TinyDB)
  • Maté
  • An infrastructure for building virtual machines
  • Provide safe, efficient high-level programming
    environments
  • Several programming models simple scripts,
    Scheme, TinySQL
  • TinySQL
  • A sensor network query language
  • Simple, well-adapted to data-collection
    applications

34
The Maté Approach
  • Goals
  • Support reprogrammability, nicer programming
    models
  • While preserving efficiency and increasing
    reliability
  • Sensor networks are application specific.
  • We dont need general programming nodes in
    redwood trees dont need to locate snipers in
    Sonoma.
  • Solution an application specific virtual machine
    (ASVM).
  • Design an ASVM for an application domain,
    exposing its primitives, and providing the needed
    flexibility with limited resources..

35
The Maté Approach
  • Reprogrammability
  • Transmit small bytecoded programs.
  • Reliability
  • The bytecodes perform runtime checks.
  • Efficiency
  • The ASVM exposes high-level operations suitable
    to the application domain.
  • Support a wide range of programming models,
    applications
  • Decompose an ASVM into a
  • core, shared template
  • programming model and application domain
    extensions

36
ASVM Architecture
37
ASVM Template
  • Threaded, stack-based architecture
  • One basic type, 16-bit signed integers
  • Additional data storage supplied by
    language-specific operations
  • Scheduler
  • Executes runnable threads in a round-robin
    fashion
  • Invokes operations on behalf of handlers
  • Concurrency Manager
  • Analyses handler code for shared resources
    (conservative, flow insensitive, context
    insensitive analysis).
  • Ensures race free and deadlock free execution
  • Program Store
  • Stores and disseminates handler code

38
ASVM Extensions
  • Handlers events that trigger execution
  • One-to-one handler/thread mapping (but not
    required)
  • Examples timer, route forwarding request, ASVM
    boot
  • Operations units of execution
  • Define the ASVM instruction set, and can extend
    an ASVMs set of supported types as well as
    storage.
  • Two kinds primitives and functions
  • Primitives language dependent (e.g., jump, read
    variable)
  • Can have embedded operands (e.g., push constant)
  • Functions language independent (e.g., send())
  • Must be usable in any ASVM

39
Maté scorecard
  • Expressivity
  • By being tailored to an application domain

40
Maté scorecard
  • Expressivity
  • Real-time requirements
  • Just say no!

41
Maté scorecard
  • Expressivity
  • Real-time requirements
  • Just say nesC!

42
Maté scorecard
  • Expressivity
  • Real-time requirements
  • Constant hardware evolution
  • Presents a hardware-independent model
  • Relies on nesC to implement it

43
QueryVM an ASVM
  • Programming Model
  • Scheme program on all nodes
  • Application domain
  • multi-hop data collection
  • Libraries
  • sensors, routing, in-network aggregation
  • QueryVM size
  • 65 kB code
  • 3.3 kB RAM

44
QueryVM Evaluation
  • Simple collect light from all nodes every 50s
  • 19 lines, 105 bytes

45
Simple query
  • // SELECT id, parent, light INTERVAL 50
  • mhop_set_update(100) settimer0(500)
    mhop_set_forwarding(1)
  • any snoop() heard(snoop_msg())
  • any intercept() heard(intercept_msg())
  • any heard(msg) snoop_epoch(decode(msg,
    vector(2))0)
  • any Timer0()
  • led(l_blink l_green)
  • if (id())
  • next_epoch()
  • mhopsend(encode(vector(epoch(), id(),
    parent(), light())))

46
QueryVM Evaluation
  • Simple collect light from all nodes every 50s
  • 12 lines, 105 bytes
  • Conditional collect exponentially weighted
    moving average of temperature from some nodes
  • 32 lines, 167 bytes
  • SpatialAvg compute average temperature,
    in-network
  • 31 lines, 127 bytes
  • or, 117 lines if averaging code in Scheme

47
Maté scorecard
  • Expressivity
  • Real-time requirements
  • Constant hardware evolution
  • Reliability
  • Runtime checks
  • Reprogramming always possible

48
Maté scorecard
  • Expressivity
  • Real-time requirements
  • Constant hardware evolution
  • Reliability
  • Extremely limited resources
  • VM expresses application logic in high-level
    operations
  • But, dont try and write an FFT!

49
QueryVM Energy
  • Ran queries on 42 node network
  • Compared QueryVM to nesC implementation of same
    queries
  • Fixed collection tree and packet size to control
    networking cost.
  • QueryVM sometimes uses less energy than the nesC
    code.
  • Due to vagaries of radio congestion (nesC nodes
    all transmitting in synch)
  • Decompose QueryVM cost using a 2-node network.
  • Run with no query base cost (listening for
    messages).
  • Ran programs for eight hours, sampling power draw
    at 10KHz
  • No measurable energy overhead!
  • Theres not much work in the application code

50
Maté scorecard
  • Expressivity
  • Real-time requirements
  • Constant hardware evolution
  • Reliability
  • Extremely limited resources
  • Reprogramming
  • Enough said already

51
Maté scorecard
  • Expressivity
  • Real-time requirements
  • Constant hardware evolution
  • Reliability
  • Extremely limited resources
  • Reprogramming
  • Easy programming
  • The good simple threaded event-processing model
  • The bad scripting languages dont make writing
    distributed algorithms any easier

52
3 Practical Programming Systems
  • nesC
  • A C dialect designed to address sensor network
    challenges
  • Used to implement TinyOS, Maté, TinySQL (TinyDB)
  • Maté
  • An infrastructure for building virtual machines
  • Provide safe, efficient high-level programming
    environments
  • Several programming models simple scripts,
    Scheme, TinySQL
  • TinySQL
  • A sensor network query language
  • Simple, well-adapted to data-collection
    applications

53
TinySQL
  • nesC, Scheme are both local languages
  • A lot of programming effort to deal with
    distribution, reliability
  • Example distributed average computation

54
In-network averaging
  • any maxdepth 5 // max routing tree depth
    supported
  • any window 2 maxdepth
  • // The state of an average aggregate is an
    array containing
  • // counts for 'window' epochs
  • // sums for 'window' epochs
  • // the number of the oldest epoch in the
    window
  • any avg_make()
  • any Y make_vector(1 2 window)
  • vector_fill!(Y, 0)
  • return Y
  • // The epoch changed. Ensure epoch 1 is
    inside the
  • // window.
  • any avg_newepoch(Y)
  • any start Y2 window
  • if (epoch() 1 gt start window)

for (i shift i lt window i)
Yi - shift Yi Yi -
shift window Yi window
// clear new values for (i window -
shift i lt window i) Yi 0
Yi window 0 // Update
the state for epoch 'when' with a count of 'n'
// and a sum of 'sum' any add_avg(Y, when, n,
sum) any start Y2 window if
(when gt start when lt start window)
Ywhen - start n // update
count Ywhen - start window n // update
sum // Add local result for
current epoch any avg_update(Y, val) add_avg(Y,
epoch(), 1, val)
// avg_get returns a six-byte string containg
encoded // epoch, count, sum (2 bytes each)
// where epoch is chosen so that our
descendant's // results have reached us before
we try and send // them on any avg_get(Y)
any start Y2 window any when
epoch() - 2 (maxdepth - 1 - depth()) any
tosend vector(when, 0, 0) // encode
the result for epoch 'when', but avoid //
problems if we don't know it or if we're too
// deep in the tree if (depth() gt maxdepth)
tosend0 epoch() - 256 else if (when
gt start) tosend1 Ywhen -
start // count tosend2 Ywhen -
start window // sum return
encode(tosend) any avg_buffer()
make_string(6) // Add some results from our
descendants to our state any avg_intercept(Y,
intercepted) any decoded decode(vector(2,
2, 2)) add_avg(Y, vector0, vector1,
vector2)
55
TinySQL
  • nesC, Scheme are both local languages
  • A lot of programming effort to deal with
    distribution, reliability
  • Example distributed average computation
  • TinySQL is a higher-level programming model
  • The sensor network is a database, sensors are
    attributes
  • Query it with SQL!
  • Examples
  • SELECT id, parent, temp INTERVAL 50s
  • SELECT id, expdecay(humidity, 3) WHERE parent gt 0
    INTERVAL 50s
  • SELECT avg(temp) INTERVAL 50s

56
TinySQL Two Implementations
  • TinyDB the original
  • A nesC program which interprets TinySQL queries
  • TinySQLVM (aka QueryVM)
  • Maté VM running Scheme
  • TinySQL queries compiled to Scheme application
  • Comparable performance, flexibility
  • TinySQLVM uses 5-20 less energy than TinyDB on
    the three example queries
  • 4 months operation on 2 AAs (15-node,
    plant-watering app)
  • TinyDB can run multiple queries
  • TinySQLVM allows user-written extensions to
    TinySQL

57
TinySQL scorecard
  • Expressivity
  • Limited to a single kind of application

58
TinySQL scorecard
  • Expressivity
  • Real-time requirements
  • We wont go there

59
TinySQL scorecard
  • Expressivity
  • Real-time requirements
  • Constant hardware evolution
  • Presents a hardware-independent programming model

60
TinySQL scorecard
  • Expressivity
  • Real-time requirements
  • Constant hardware evolution
  • Reliability
  • You cant express any nasty bugs ?

61
TinySQL scorecard
  • Expressivity
  • Real-time requirements
  • Constant hardware evolution
  • Reliability
  • Extremely limited resources
  • Little computation required
  • Can perform high-level optimisations (see the
    many TinyDB papers)

62
TinySQL scorecard
  • Expressivity
  • Real-time requirements
  • Constant hardware evolution
  • Reliability
  • Extremely limited resources
  • Reprogramming
  • Is not a problem

63
TinySQL scorecard
  • Expressivity
  • Real-time requirements
  • Constant hardware evolution
  • Reliability
  • Extremely limited resources
  • Reprogramming
  • Easy programming
  • Simple, declarative, whole system programming
    model

64
Related Work nesC
  • Other component and module systems
  • Closest are Knit and Mesa
  • None have our desired features component-based,
    compile-time wiring, bi-directional interfaces
  • Lots of embedded, real-time programming languages
  • Giotto, Esterel, Lustre, Signal, E-FRP
  • Stronger guarantees, but not general-purpose
    systems languages
  • Component architectures in operating systems
  • Click, Scout, x-kernel, Flux OSKit, THINK
  • Mostly based on dynamic dispatch, no
    whole-program optimization

65
Related Work ASVMs
  • JVM, KVM, CLR
  • Designed for devices with much greater resources
    100 KB RAM
  • Java Card
  • An application specific JVM for smart cards
  • Many of the same principles apply (constraints,
    CAP format)
  • SPIN, Exokernel, Tensilica, etc.
  • Customizable boundaries for application
    specificity
  • Impala/SOS
  • Support incremental binary updates easy to crash
    a system

66
Scorecards
C nesC Maté TinySQL
Expressivity
Real-time ? ?
Hardware evol. ?
Reliability ?
Limited resources
Reprogramming ? ?
Easy to use ? ?
67
And the Winner is
  • nesC
  • High performance, suitable for any part of an
    application
  • But, harder to program, bugs may bring down
    system
  • Maté
  • Safe, simple programming environments
  • But, limited performance best for scripting,
    not radio stacks
  • TinySQL
  • Easiest to use
  • But, limited application domain
  • Why not use all three?
  • Extend TinySQL with Maté (Scheme) code
  • Extend Maté with new functions, events written in
    nesC

68
Conclusion
  • Sensor networks raise a number of programming
    challenges
  • Very limited resources
  • High reliability requirements
  • Event-driven, concurrent programming model
  • nesC and Maté represent two different tradeoffs
    in this space
  • nesC maximum performance and flexibility, some
    reliability through compile-time checks, harder
    programming
  • Maté efficiency for a specific application
    domain, full reliability through runtime checks,
    simpler (scripting) to simple (TinySQL)
    programming

69
(No Transcript)
70
Service Instance support multiple instances
with efficient collaboration
  • Consequences
  • clients remain independent, configurability imple
    mentation can coordinate
  • clients guaranteed that service is
    available robustness
  • service automatically sized to application
    needs efficiency
  • static allocation may be wasteful if worst case
    simultaneous users lt different users

71
Placeholder allow easy, application-wide
selection of a particular service implementation
  • Consequences
  • defines global names for common
    services replaceability
  • easy application-wide implementation selection
  • no runtime cost efficiency

72
Conditional query
  • // SELECT id, expdecay(light, 3) WHERE (parent gt
    0) INTERVAL 50
  • any expdecay_make(bits) vector(bits, 0)
  • any expdecay_get(s, val) s1 s1 - (s1 gtgt
    s0) (val gtgt s0)
  • any s_op1 expdecay_make(3)
  • mhop_set_update(100) settimer0(500)
    mhop_set_forwarding(1)
  • any snoop() heard(snoop_msg())
  • any intercept() heard(intercept_msg())
  • any heard(msg) snoop_epoch(decode(msg,
    vector(2))0)
  • any Timer0()
  • led(l_blink l_green)
  • if (id())
  • next_epoch()
  • if (parent() gt 0)
  • mhopsend(encode(vector(epoch(), id(),
    expdecay_get(s_op1, light()))))

73
Spatial query
  • // SELECT avglight INTERVAL 50
  • mhop_set_update(100) settimer0(500)
    mhop_set_forwarding(0)
  • any s_op1 avg_make()
  • any snoop() snoop_epoch(decode(snoop_msg(),
    vector(2))0)
  • any intercept()
  • vector fields decode(intercept_msg(),
    vector(2, avg_buffer()))
  • snoop_epoch(fields0)
  • avg_intercept(s_op1, fields1)
  • any epochchange() avg_newepoch(s_op1)
  • any Timer0()
  • led(l_blink l_green)
  • if (id())
  • next_epoch()
  • avg_update(s_op1, light())
  • mhopsend(encode(vector(epoch(),
    avg_get(s_op1))))
About PowerShow.com