• Controlled sharingA programmer specifies constraints on how components may be shared The compiler shares declared components whenever possible:

is compiled to the equivalent of:

• ParametersComponents and services can take a list of named parameters:

And these parameters can be loose:

• Connectedness constraintsRestrictions such as @once (exactly once), @least (at least once), and@most (at most once) affect how interfaces may be used:

And these restrictions affect sharing:

• Exclusive instantiationSharing may be prevented with the type constraint “my”These EWMAs have compatible parameters:

But Sensor1 and Sensor2 will each get a unique EWMA instance

• Service weavingTransitive arrows express non-local relationships:

Services using transitive arrows may be woven together:

lqe and tree share a MsgSrc, a MsgSink, and a Network

• Comparison of two versions of a simple SNACK data forwarder with Surge, a similar nesC application– SnackForwarder, or SF: collects temperature and light data and

forwards up a routing tree– SF-NoTransitive: A version of SF that does not take advantage

of non-local connections– Surge: The Surge application modified to sample light and

temperature

• Application resource allocation (bytes)– SF uses 30% more ROM than Surge, but 3% less RAM– All values are well within the Mica2’s operating constraints

• Resource allocation by component– These components together acount for 44% of SF’s ROM

and 42% of its RAM

• Messaging RAM allocation– Maximum dynamic memory pool usage (49-node simulations)– Static TOS_Msg allocation

• Bytes sent as a function of network size– 600-second simulations at varying network sizes

– Transitive arrows let unrelated application components share packets so that fewer bytes are transmitted

Sensor Network Application Construction Kit (SNACK)Sensor Network Application Construction Kit (SNACK)Ben Greenstein, Eddie Kohler, Deborah Estrin

CENS Systems Lab – http://lecs.cs.ucla.edu

Introduction:Introduction: It Should be Easier to Develop Efficient Applications It Should be Easier to Develop Efficient Applications

Efficiency Adds Program Complexity• Application developers reach into and manipulate system-level

code to provide optimized service• Components, initializations and connections are handcrafted for

each developed application – optimized by eye, not by a compiler• Cross-dependencies between application services, which are

necessary for efficiency, prevent modularity

Overcoming Complexity Requires Language Support

• Independently written library services must be able to cooperate to configure and share underlying resources

• Language support must be provided to specify constraints on the context in which an application service is designed to run

• Solving the constraint system imposed by all services in an application requires a compiler

 

Language Design Compiler

UCLA – UCR – Caltech – USC – CSU – JPL – UC MercedUCLA – UCR – Caltech – USC – CSU – JPL – UC Merced

Center for Embedded Networked SensingCenter for Embedded Networked Sensing

Performance• SNACK’s compiler reduces the recursive expansion of an

application’s services to a maximally shared expansion:– That has the minimum number of instances of any valid expansion– Where every connection in the fully expanded input program

corresponds to a connection in the maximally shared expansion– Where all components and connections are justified by the input

program

• The maximally shared expansion is found by exhaustive search and must pass four tests:

– Interface constraints: No @most or @once interface may be directly connected more than once

– Parameters: The linear system of all component and service parameters has a solution

– “my” constraints: Two components of the same type may only be shared if recursively imposed “my” constraints do not preclude it

– Transitive connections: a valid assignment of transitive connections exists

• Heuristics reduce the search space: – Search is ordered by cardinality of expansion so the first valid

expansion is the smallest– Obviously incorrect expansions eliminated from consideration– For each component type the smallest expansion subset that

contains no obvious problems is memoized– When an invalid expansion is found, the search is advanced to the

next expansion that might affect the problem, rather than wasting time on expansions that would definitely have the same problem

Application ROM RAM

SF18,80

61,867

SF-NoTransitive

24,096

3,077

Surge14,56

41,921

Description Component ROM RAM

Attribute Access AttrM 2,038 0

Memory MemoryPoolM 2,758 302

Link Quality LinkEstimatorM 1,306 51

Communication NetworkM 958 319

Periodic Messages

MsgSrcM 788 48

Tree Construction TreeBuilderM 852 19

Tree TransportTreeDispatch16M 280 36

ApplicationRO

MRAM

SF 172 308

SF-NoTransitive

188 1,232

Surge N/A 836

A[MsgRcv] -> Network; B[MsgRcv] -> Network;

n::Network; A[MsgRcv] -> n; B[MsgRcv] -> n;

service SmoothSenseTemp(period:max uint32_t $p = 1000){ my sense :: SenseTemp(period = $p); // Could also multiply by a constant: ‘period = 2 * $p’}

sense :: SenseTemp(period >= 20, period <= 60);

t :: TreeBuilderM [Put32 @most] -> …

// t1 and t2 cannot be the same instance:t1 :: TimeSrc(period = 10) [Timer @once] -> Sensor1;t2 :: TimeSrc(period = 10) [Timer @once] -> Sensor2;

service SmoothedSensor1 { Sensor1[Put16] -> my EWMA(alpha = 0.4) -> out;}service SmoothedSensor2 { Sensor2[Put16] -> my EWMA(alpha = 0.4) -> out;

n::Network; tree::TreeBuilderM; lqe::LinkEstimatorM;MsgSrc (period = 5000)[outbound] -> tree -> lqe -> n;n[inbound] -> tree -> lqe -> MsgSink;

service LinkEstimator(period: max uint32_t $p = 5000){ lqe :: my LinkEstimatorM(…, period = $p); lqe [AttrAccess] -> AttrM; //… MsgSrc (period <= $p) [outbound] ..> lqe ..> Network Network [inbound] ..> lqe ..> MsgSink;}

service TreeBuilder(period: max uint32_t $p = 10000){ tree :: TreeBuilderM(period = $p); lqe :: LinkEstimator(period <= $p); in [lookup] -> tree; //… MsgSrc(period <= $p)[outbound] ..> tree ..> Network; Network [inbound] ..> tree ..> MsgSink;}

Proposed Solution:Proposed Solution: A New Way to Compose Sensor Network ApplicationsA New Way to Compose Sensor Network Applications

The Details:The Details: Language Design, Compilation Strategy, and Performance Results Language Design, Compilation Strategy, and Performance Results

Compilation Example

RoutingTreeLightSense TempSenseRoutingTree

Link EstimatorM

Network

TreeBuilderM

MsgSink MsgSrc

NullFwd16 1

NullFwd16 2

TimeSink

TreeDispatch16 1

TreeDispatch16 2

TimeSrc

Sense 2

Sense 1

Photo

Temp

LinkEstimator

Network

NullFwd16

TimeSrc

RoutingTreeLightSense

MsgSink MsgSrc

TimeSink

Photo Sense NullFwd16

TimeSrc MsgSink MsgSrc

TimeSink

Temp Sense

RoutingTreeTempSense

Network

MsgSink MsgSrc

Network

MsgSink MsgSrc

TreeBuilder

TreeBuilderM

TreeDispatch16

LinkEstimator

Network

MsgSink MsgSrc

Network

MsgSink MsgSrc

TreeBuilder

TreeBuilderM

Network

TreeDispatch16

LinkEstimatorM LinkEstimatorM

Compiler produces maximally shared expansion

Merger of compatible components from both halves into single instances

Light-sampling part of the application

Temperature-sampling part of the application

Application specified by connecting a few application-level services

Services are expanded into components

• Component programming models reduce development complexity• However, component models don’t yet support the construction

of independent application-level service libraries that can be reused from one application to the next to produce efficient applications

Language, Library, and Compiler For Example:SenseTemp(period = 10000) -> [collect] my RoutingTree;SenseLight(period = 20000) -> [collect] my RoutingTree;

• Declares that temperature and light data should be collected using a routing tree • Sampling should occur once every 10 and 20 seconds respectively• Each sensing modality needs state to maintain its own connection to a routing tree• Two routing tree services are declared, but after compilation, many of their

underlying components will be shared

ApplicationPacke

tControl Data Total

SF [4] 876.0 300.3 442.51618.

8

SF [16] 1240.7 362.51034.

92638.

0

SF [49] 1282.8 363.01126.

32772.

1

SF-NoTransitive [4]

2330.7 505.1 429.63265.

3

SF-NoTransitive [4]

2930.3 602.71209.

24742.

2

SF-NoTransitive [4]

3096.2 630.91336.

35063.

4

Surge [4] 1073.3 1345.72419.

0

Surge [16] 2491.4 3087.15578.

5

Surge [49] 2892.1 3497.56389.

6

Network

NullFwd16

TimeSrc

TreeDispatch16

RoutingTreeLightSense

TreeBuilder

Partial Expansion: RoutingTree, Dispatch, and Samplers

MsgSink MsgSrc

TimeSink

Photo Sense

Network

NullFwd16

TimeSrc

TreeDispatch16

TreeBuilder

MsgSink MsgSrc

TimeSink

Temp Sense

RoutingTreeTempSense