Real World Applications

Four real world applications are selected for the investigation of AUTO_GS concept: Video Object Plan Decoding (VOPD), MPEG4 video decoding, Picture-In-Picture (PIP) and Multi-Windows Display (MWD). These high-end video processing applications possess diverse communication requirements and are widely used for System on Chip performance eval-uations [133] [98]. Bertozzi et al. represented the communication behavior of these

appli-0.2 0.4 0.6 0.8

Figure 3.6.: Communication related energy consumption for synthetic traffic

cations in the form of application core graphs [9]. They have also proposed the mapping of the application tasks on the processing cores through an algorithm, which optimizes the communication between the cores. We have used the same application task mapping in our simulation framework which is proposed by the above-mentioned state of the art concept. The application task mapping results in the allocation of a given number of cores to each application. Mapping of an application to the number of processing cores and the application execution time while using only best effort communication are provided in the table 3.1. Each application is mapped independently to the center of the mesh for each simulation run. The number of monitored communication flowsAUTO_GSconnis chosen by keeping in view the assigned processing cores to each application. AUTO_GS_cycleis changed to three different values in respective different scenarios to check its impact on the performance of our concept. In the first scenario, AUTO_GS_cycle is set to 41.6µsec, which represents the lowest possible value of monitoring interval according to the

rela-3.1. Communication Resource Management Application Number of cores Execution time (ms)

VOPD 12 5.6

MPEG 14 6.3

PIP 8 4.3

MWD 14 5.7

Table 3.1.: Real world video processing applications

tion 3.1. Subsequently, the monitoring interval is increased to multiple of this value in two further scenarios. Monitoring interval is always less than the execution time of each application. The remaining simulation parameters are chosen to be the same as in the case of synthetic traffic evaluations.

Figure 3.7 shows the total amount of traffic which is generated by the four applications over the network. AUTO_GS configuration leads to significantly less traffic for real world applications when compared with the Reference configuration. In the Reference configu-ration, a centralized software instance decides to use GS or BE communication depend-ing on the monitordepend-ing information. In the proposed AUTO_GS configuration, the hard-ware support in the network interface is responsible for assigning the communication resources. Hardware-controlled GS connections react faster to the run-time traffic condi-tions as compared to the Reference and hence major share of the traffic uses connection-oriented communication. The difference in the amount of traffic reduction between the two configurations is different for each application, which depends on its communica-tion behavior. MPEG and VOPD applicacommunica-tions have higher communicacommunica-tion demands and possess heterogeneous communication requirements between different nodes in compar-ison to other two applications. Therefore, both of these applications show more reduction in network utilization compared to PIP and MWD, when AUTO_GS concept is applied.

When the monitoring interval is increased in three different scenarios, the saving in the amount of traffic is reduced for MPEG application. Other applications do not show an observable difference when monitoring interval is changed. This is due to the fact that the MPEG application shows more variation in its communication behavior over time as compared to other applications.

Figure 3.8 shows the average packet latency while executing the four applications. All applications profit from AUTO_GS concept in terms of packet latency. The packet latency of MPEG in the case of the Reference is higher as compared to the other applications. This is due to the fact that the MPEG generates higher network load. AUTO_GS brings a re-duction of 35% in packet latency for MPEG application. In the case of VOPD application, the average packet latency is reduced by 26% in AUTO_GS configuration as compared to the Reference configuration. MWD and PIP being low bandwidth applications profit rel-atively less from our concept as compared to MPEG and VOPD. The impact of increasing monitoring interval can be observed in the form of increased average packet latency for MPEG application. Similar to network utilization evaluations, other applications do not see the observable difference in packet latency when the monitoring interval is changed.

Figure 3.9 shows the energy consumption for the applications. The communication-related energy consumption was analyzed for each application as explained in the evaluations for synthetic traffic. The PIP and MWD applications, which have relatively low bandwidth

MPEG MWD PIP VOPD 0

1 2 3 4

· 10⁵

TotalNumberofFlits

Reference AUTO_GS

(a)AUTO_GScycle= 41.6µsec

MPEG MWD PIP VOPD

0 1 2 3 4

· 10⁵

TotalNumberofFlits

Reference AUTO_GS

(b)AUTO_GScycle= 83.2µsec

MPEG MWD PIP VOPD

0 1 2 3 4

· 10⁵

TotalNumberofFlits

Reference AUTO_GS

(c)AUTO_GScycle= 124.8µsec

Figure 3.7.: Network utilization for real world applications

requirements, reduce their communication-related energy consumption by around 25% if AUTO_GS configuration is deployed. VOPD and MPEG show a reduction of around 30%

and 33% in consumed energy as compared to the Reference configuration. The amount of energy saving reduces with the increase in monitoring interval for MPEG application following the same reason as stated in network utilization and packet latency results. The evaluations which are presented above, highlight that hardware managed GS connections lead to better utilization of communication resources and reduce the communication la-tencies suffered by applications. In addition, energy consumed by the communication infrastructure is reduced. The details of the hardware extensions in the network interface design which correspond to the proposed concept are provided in section 4.2.