30.07.2015 Views

Actas JP2011 - Universidad de La Laguna

Actas JP2011 - Universidad de La Laguna

Actas JP2011 - Universidad de La Laguna

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

<strong>Actas</strong> XXII Jornadas <strong>de</strong> Paralelismo (<strong>JP2011</strong>) , <strong>La</strong> <strong>La</strong>guna, Tenerife, 7-9 septiembre 2011TABLE ICPU utilization (%) of the computer hosting the VCP.Agents Acting Period (ms.)100 400 700 10003000 69 67 65 556000 100 100 100 1009000 100 100 100 10012000 100 100 100 100the difference between the number of operations sentby the ASs and the number of operations actuallyprocessed by the VCP. Table II shows these data,and it shows that for 3000 agents there are no lostoperations (the CPU hosting the VCP is not saturated,reaching a maximum CPU utilization of 69%for the lowest acting period (100 ms). However, from6000 agents up, the VCP does not process all the requests,<strong>de</strong>pending on the agent period. It is worthmention that for the case of 6000 agents the VCP iscapable of process all the operations received whenusing an acting period of 700 and 1000 ms. However,when simulating 12000 agents the VCP cannot processall the operations, regardless of the agent periodconsi<strong>de</strong>red. These results show that the implementationof the VCP should reduce the CPU utilizationassociated to the graphic tasks as much as possible,in or<strong>de</strong>r to increase the VCP throughput.or received from other ASs and CPs are exchangedasynchronously. This means that the AE threadsonly may have to wait when accessing the semanticdatabase.The changes required in the Action Server forconnecting the VCP exclusively affects the InterfaceModule. Figure 2 shows the general scheme of an ActionServer modified for accepting VCP connections.Two I/O threads are created for each VCP connectedto an AS. One of the I/O threads receives, through asocket, the MBR frustum updates sent by the VCP.It must be noticed that the updates received fromthe VCP are not passed to the Crowd AS ControlModule. In this way, the workload ad<strong>de</strong>d by eachVCP connected to the AS is reduced. The other I/Othread is in charge of forwarding to the VCP theAS replies to agents requests. This thread uses theMBR frustum updates received from the VCP to filterforwar<strong>de</strong>d replies. It simply checks whether anagent falls within the MBR frustum or not (see Figure1). In this way, a VCP can visualize less agentsthan those that form the crowd simulated by the distributedsystem.TABLE IIVisualization requests not processed by the VCP.AgentsActing Period (ms.)100 400 700 10003000 0 0 0 06000 76207 44729 0 09000 205545 238244 61972 012000 433716 391644 157606 19137IV. Distributed Ren<strong>de</strong>ring of CrowdSimulationsIn this section we <strong>de</strong>scribe the proposed implementationof the Visual Client Process. The proposedapproach for ren<strong>de</strong>ring crowd simulation is based onhaving each VCP connected with one or more ActionServers. Therefore, the first step is to modifythe AS scheme proposed in [7] in such a way thatthe information about the agent actions is also sentto the VCPs. Then, an implementation of the VCPaccording to that scheme should be <strong>de</strong>veloped.A. Modifications to the Action ServerEach AS process [7] contains three basic elements:the Interface module, the Crowd AS Control (CASC)module and the Semantic Data Base (SDB). The Interfacemodule is in charge of communicating theAS with other ASs and CPs. The main module isthe Crowd AS Control module, which is responsiblefor executing the crowd actions. This module containsa configurable number of threads for executingactions (action execution threads). For an actionexecution thread (AE thread), all messages sent toFig. 2.Scheme of an Action Server with VCP connections.B. Implementation of the Visual Client ProcessThe VCP is mainly composed by two modules: theInterface Module and the Graphic Application Module.Figure 3 shows an schematic view of this process.The Interface Module is in charge of sending updatesof the MBR frustum to the ASs. Also , this moduleshould receive agents updates and pass them to theGraphic Application Module. The Graphic ApplicationModule is in charge of performing the graphictasks. Some of these tasks are executed on the CPUand other ones are executed on the GPU.As shown in section III, it is crucial to reduce asmuch as possible the percentage of CPU utilization inthe computer hosting the VCP in or<strong>de</strong>r to minimizethe number of visualization updates not processedby the VCP. In or<strong>de</strong>r to achieve this goal, the frustumculling and the <strong>de</strong>termination of the Level Of<strong>JP2011</strong>-337

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!