Mobile Ad Hoc Networking (Cutting Edge Directions) || Task Farming in Crowd Computing

Download Mobile Ad Hoc Networking (Cutting Edge Directions) || Task Farming in Crowd Computing

Post on 09-Dec-2016




0 download

Embed Size (px)


<ul><li><p>13TASK FARMING IN CROWDCOMPUTING</p><p>Derek G. Murray, Karthik Nilakant, J. Crowcroft,and E. Yoneki</p><p>ABSTRACT</p><p>Crowd computing combines mobile devices and social interactions to achieve large-scale distributed computation, by taking advantage of the substantial aggregate band-width and processing power offered by opportunistic networks. In this chapter weanalyze human contact network traces to place an upper bound on the amount ofcomputation that is possible in such networks. We also investigate a practical task-farming algorithm that approaches this upper bound in parallel mobile computingand show that exploiting social structure can dramatically increase its performance.Opportunistic networks are highly dynamic, and we expect that an adaptive systemwill lead to improved performance. We will end the chapter by briefly introducing ourfuture work on investigation of programming models that directly exploit differenttask farming strategies. For example, we rely on direct masterworker encounters inorder to relay results, but it would be possible to do better by using opportunisticforwarding or taking advantage of social structure.</p><p>13.1 INTRODUCTION</p><p>The computational resources available on modern smartphones are largely unhar-nessed in the field of distributed computing. As of 2011, smartphones typically fea-ture hardware capabilities similar to those of low-end laptop computers. For instance,</p><p>Mobile Ad Hoc Networking: Cutting Edge Directions, Second Edition. Edited by Stefano Basagni,Marco Conti, Silvia Giordano, and Ivan Stojmenovic. 2013 by The Institute of Electrical and Electronics Engineers, Inc. Published 2013 by John Wiley &amp; Sons, Inc.</p><p>491</p></li><li><p>492 TASK FARMING IN CROWD COMPUTING</p><p>the Apple iPhone 4 was released with a one-gigahertz processor, half a gigabyteof RAM, and 64 gigabytes of flash storage. Graphical processing units and digitalsignal processors are also commonplace in modern devices [1]. In addition, thesedevices contain a variety of hi-fidelity sensors such as cameras, accelerometers, mi-crophones, and GPS receiverssuch sensors are not commonly found on traditionalpersonal computers. Network connectivity is obviously one of the core aspects of anysmartphone, and most feature multiple radio network interfaces: a high-bandwidthcellular data-capable connection; 802.11 WiFi connectivity; Bluetooth and near-fieldcommunication technology. These features, combined with the increasing popularityof such devices, make the prospect of distributed computing frameworks that utilizeclusters of smartphones a viable opportunity.</p><p>A fundamental difference between networks for conventional distributed comput-ing and networks of mobile devices is the level of dynamism. Nodes and links in thenetwork are continuously appearing and disappearing, at a much higher rate than infixed infrastructure or datacenter networks. In order to to exploit the computationalcapacity of a group of mobile devices, a delay-tolerant approach needs to be adopted.Networking platforms such as Haggle [2] are designed to cope with this type ofactivity. Datacenter systems such as MapReduce [3] are designed with the ability tohandle node failures, and we envision that some of these capabilities can be adapted toa highly dynamic crowd computing environment. Dataflow programming techniques(for example, Skywriting [4] and Ciel [5]) can be adopted for efficient parallel pro-gramming over these delay-tolerant clusters, allowing integration with conventionalcloud-based computation.</p><p>Our guiding principle is a familiar mantra: Once the data become large, the com-putation must be moved to the data. Mobile devices can store tens of gigabytes ofdata and can also be used as collection points for data. As summarized in Figure 13.1,</p><p> Sensor readings Media Web cache User knowledge</p><p>Figure 13.1 Diagram illustrating the importance of data and execution placement in thenetwork.</p></li><li><p>INTRODUCTION 493</p><p>for instance, a device may contain readings from its various sensors; media suchas photos, music, and videos; or cached data from the web. Perhaps the most im-portant data source is the human being who is carrying the phone, and who cananswer questions or perform short tasks that cannot efficiently be performed by amachine.</p><p>Inspired by the increasing prevalence of smartphones, along with research intoopportunistic networking [6], we have evaluated the potential of using these devicesto carry out large-scale distributed computations. In this chapter we describe crowdcomputing [7], in which opportunistic networks can be used to spread computationand collect results. A small job or task descriptor is disseminated amongst the crowd,processing is performed in parallel by the mobile devices, and finally the results arereduced or aggregated in order to be shipped back cheaply to the initiator.</p><p>A crowd computation spreads opportunistically through a network, using ad hocwireless connections that form as devices come into proximity. Devices can exchangeinput data and intermediate results. In parallel work, we are developing programminglanguages that enable developers to implement a crowd computation [4,8]; this chapterfocuses on the aggregate utility of such a computation, in terms of how much workeach device can carry out.</p><p>Previous work has shown that people will voluntarily contribute their desktopcomputer resources for running scientific workloads [9]. One might imagine a sim-ilar application for mobile devices, perhaps providing free content or functionalityin exchange for volunteered cycles. Furthermore, unusual devices such as graphicscards [10] and games consoles [11] have been used to perform high-throughput com-puting. A modern smartphone has several special-purpose cores (such as DSPs andA/V codecs) [1], which could similarly be applied to large-scale problems. More-over, the combined bandwidth available in these networks can facilitate large-scalecomputation [12].</p><p>Alternatively, we can use crowd computing as a means of distributing human in-teraction tasks to mobile devices. For example, Amazon Mechanical Turk has createda marketplace for carrying out work that is difficult for computers to process, but rel-atively simple for humans [13]. Many qualitative classification tasks are much easierfor humans than for computers. By combining this model with crowd computing, itwould be possible to exploit geographic locality in the respondents.</p><p>We begin by establishing a practical limit for the computational capacity of anopportunistic network (Section 13.2). We contrive an idealized distributed computa-tion that can spread epidemically with negligible data exchange, and we simulate itsexecution on a variety of human encounter traces, collected from various academicenvironments. By positing that each person in the trace possesses a smartphone, wecan measure the total work done by simulation.</p><p>Clearly, most of the assumptions of the previously described model are not realisticfor most networks. We therefore consider the common task farming approach, and weevaluate its performance on the same traces (Section 13.3). We find that, on average,it achieves 40% of the performance of our ideal computation. Switching to a concretemodel introduces more variableswe consider the effect of master choice, task size,and node capacity on the overall utility of the system.</p></li><li><p>494 TASK FARMING IN CROWD COMPUTING</p><p>We build on previous work that has shown how social network analysis can im-prove the efficiency of message forwarding in opportunistic networks [14,15]. Weinvestigate how a similar technique can be used to improve the performance of taskfarming (Section 13.4). In particular, we observe that dividing an opportunistic net-work into communities, along with running a separate task farm within each com-munity, improves the throughput of task farming by an average of 50%. Selection ofhigh centrality nodes as masters produces a significant improvement.</p><p>In this chapter we aim to show that an opportunistic network of mobile devices is afeasible platform for distributed computation. Our results demonstrate that such net-works can provide a high degree of parallelism. We are currently developing the firstcrowd computing applications that exploit this approach. While the results presentedin this chapter do not constitute a comprehensive validation of the performance ofcrowd computing, there are several areas that show promise, and this indicates thatfurther research is necessary.</p><p>13.2 IDEAL PARALLELISM MODEL</p><p>We first determine the maximal amount of computation achievable in an opportunisticnetwork. The goal of a crowd computation is to have long periods of useful parallelism.This means that a device must not only receive a message that causes it to jointhe computation, but must also send a message containing its result that eventuallyreaches the initiator (Figure 13.2). In this section we first define our model of an idealdistributed computation (Section 13.2.1) and then apply it on real-world encountertraces (Section 13.2.2).</p><p>13.2.1 Definitions</p><p>We assume a set of n identical mobile devices that participate in the computation.Device zero is the initiator, and it starts computing (becomes active) at time 0.</p><p>Dev</p><p>ices</p><p>Figure 13.2 The progress of a computation in a network of five nodes. Each arrow correspondsto an encounter between nodes. Bold black lines correspond to useful computation, and boldgray lines correspond to wasted computation.</p></li><li><p>IDEAL PARALLELISM MODEL 495</p><p>For optimal delivery, coordination and result messages spread by flooding. All de-vices listen for radio transmissions at all times; all active devices continually broadcasta probe message to discover nearby devices.1</p><p>When an active device meets another device, a sequence of messages is exchanged.First, the active device sends a message describing the computation. On receiving thismessage, an inactive device becomes active: thus the computation floods throughoutthe network. Each active device stores a partial result that includes the result of itscomputation, and any partial results received from other devices. When two devicesmeet, they exchange their stored partial results: this ensures that the results also floodthrough the network, which maximizes the probability that these results reach theinitiator.</p><p>Finally, at time 0 the initiator ends the computation,2 and it computes the finalresult from the messages that it has received.</p><p>Consider device i. It starts computing at i. At i, it sends the last message that(in one or more hops) reaches the initiator before 0. An encounter is a tuple (i, j, t),indicating that nodes i and j meet at time t. Given a chronologically ordered sequenceof encounters, we compute i using Algorithm 13.1. We compute i by reversingthe order of the encounter trace and rerunning Algorithm 13.1 (substituting for ).</p><p>Algorithm 13.1 Algorithm for Computing iA {0}0 start timefor (i, j, t) trace do</p><p>if i A j / A thenj t, A A {j}</p><p>else if j A i / A theni t, A A {i}</p><p>end ifend for</p><p>Device i is useful for duration i, defined as follows:</p><p>i ={</p><p>i i if i &lt; i0 otherwise</p><p>(13.1)</p><p>In the ideal case, each cycle spent on the computation has constant utility. Thereforethe utility of a device, ui, equals i, and the overall utility, U, equals</p><p>i ui. In order</p><p>to achieve this, each device must be given enough work to occupy it fully betweeni and i. This requires either an omniscient scheduler or a computation that can be</p><p>1In practice, power considerations and wireless MAC protocols will limit the ability of devices to broadcastcontinually.2The initiator may broadcast 0 with the initial announcement in order to reduce the amount of wastedcomputation; however, this requires synchronized clocks.</p></li><li><p>496 TASK FARMING IN CROWD COMPUTING</p><p>repeated ad infinitum. Monte Carlo simulation is an example of the latter case. Weevaluate a simple scheduler design in Section 13.3.</p><p>13.2.2 Real-World Traces</p><p>We now evaluate the upper bound for several real-world scenarios, by applyingthe above algorithm to several human encounter traces. In this and the followingsections, we use traces from various sources. These traces can be obtained fromCRAWDAD [16]:</p><p>MIT. In the MIT Reality Mining project, 97 smartphones were deployed to stu-dents and staff at MIT over a period of 9 months [17].</p><p>Cambridge. In the Haggle project, 36 iMotes were deployed to first-yearand second-year undergraduate students at the University of Cambridge for10 days [2].</p><p>Infocom. 78 iMotes were deployed at the Infocom 2006 conference for 3 days.</p><p>In our first experiment, we consider the lifespan of a single computation. Wesimulate the execution of an ideal computation on the Cambridge trace, choosingeach device in turn as the initiator. The choice of initiator leads to varying outcomes.We record two metrics: the number of useful devices at time t, P(t), and the totalutility of the computation, U = 0</p><p>0P(t) dt. Figure 13.3 shows how P(t) changes</p><p>throughout the simulation, for the best, worst and average choices of initiator. Notethat the best case has at least 26 devices doing useful work until shortly before theend of the computation, whereas in the worst case, the initiator does not see any otherdevices after the halfway point of the computation. The average case achieves 93%of the best case total utility.</p><p>We now investigate the properties of different traces. Since each trace has a differ-ent duration and number of devices, we must normalise U in order to compare traces.</p><p>0</p><p>5</p><p> 10</p><p> 15</p><p> 20</p><p> 25</p><p> 30</p><p> 35</p><p>0 50 100 150 200 250</p><p>Para</p><p>llelis</p><p>m</p><p>Time (hours)</p><p>BestAvg.</p><p>Worst</p><p>Figure 13.3 Achievable parallelism for an ideal distributed computation using the Cambridgetrace.</p></li><li><p>IDEAL PARALLELISM MODEL 497</p><p>0</p><p> 0.2</p><p> 0.4</p><p> 0.6</p><p> 0.8</p><p>1</p><p>0 0.2 0.4 0.6 0.8 1</p><p>P(X </p><p>&lt; x)</p><p>Normalized utility</p><p>Cam.Infocom</p><p>MIT</p><p>Figure 13.4 CDFs of normalized utility for the Cambridge, MIT and Infocom traces.</p><p>Figure 13.4 shows cumulative distribution functions of utility for the Cambridge, MITand Infocom traces, normalized by the length of the trace and number of devices. TheMIT trace exhibits the poorest performance, which we suspect is due to the relativelyinfrequent encounters between devices in a diverse group of participants [17]. Bycontrast, the participants in the Cambridge and Infocom traces were more homoge-neous (all computer science undergraduates or conference attendees), and hence morelikely to occupy the same space.</p><p>The amount of useful computation depends greatly on the choice of the initiator,which we investigate further in Section 13.4. The parameters of start time (0) andfinish time (0) also have a predictable effect: Running a computation at night or atthe weekend, when encounters are rarer, leads to less parallelism and less utility. Weran one million simulated computations each lasting one hour, with the start time andinitiator chosen uniformly at random, using the Cambridge trace. Figure 13.5 shows</p><p>0</p><p>1</p><p>2</p><p>3</p><p>4</p><p>5</p><p>6</p><p>0 5 10 15 20</p><p>Rel</p><p>ativ</p><p>e ut</p><p>ility</p><p>Hour of day</p><p>Figure 13.5 Relative utility for an hour-long job in the Cambridge trace, at di...</p></li></ul>


View more >