Network Interface Architecture with Scalable Low-Latency Message Receiving Mechanism

Abstract

SUMMARYMost of scientists except computer scientists do not want to make efforts for performance tuning with rewriting their MPI applications. In addition, the number of processing elements which can be used by them is increasing year by year. On large-scale parallel systems, the number of accumulated messages on a message buffer tends to increase in some of their applications. Since searching message queue in MPI is time-consuming, system side scalable acceleration is needed for those systems. In this paper, a support function named LHS (Limited-length Head Separation) is proposed. Its performance in searching message buffer and hardware cost are evaluated. LHS accelerates searching message buffer by means of switching location to store limited-length heads of messages. It uses the effects such as increasing hit rate of cache on host with partial offloading to hardware. Searching speed of message buffer when the order of message reception is different from the receiver's expectation is accelerated 14.3 times with LHS on FPGA-based network interface card (NIC) named DIMMnet-2. This absolute performance is 38.5 times higher than that of IBM BlueGene/P although the frequency is 8.5times slower than BlueGene/P. LHS has higher scalability than ALPU in the performance per frequency. Since these results are obtained with partially on loaded linear searching on old Pentium R 4, performance gap will increase using state of art CPU. Therefore, LHS is more suitable for larger parallel systems. The discussions for adopting proposed method to state of art processors and systems are also presented. key words: network interface, MPI, message passing, queue management, low latency communication, scalability

Modeling Message Queueing Services with Reliability Guarantee in Cloud Computing Environment Using Colored Petri Nets

“…Thus the average service time of the two phases is 1/ 1 and 1/ 2 , respectively. Actually, before processing, it is time consuming to search in the message queue; thus, system side scalable acceleration is needed [45]. Nevertheless, in cloud computing environment, the scalability can be realized by adding CPUs or using state-of-the-art CPUs because multicore can execute linear searching for queue with shorter depth (i.e., message number) in parallel; as a result, the performance of queue searching can be improved easily.…”

“…Nevertheless, in cloud computing environment, the scalability can be realized by adding CPUs or using state-of-the-art CPUs because multicore can execute linear searching for queue with shorter depth (i.e., message number) in parallel; as a result, the performance of queue searching can be improved easily. Moreover, according to [45], searching speed of message queue when the order of message reception is different from the receiver's expectation is accelerated; this means the extra searching time caused by message ordering requirement is very small. In the light of these reasons and the fact that the message searching time is in microseconds, we assume that the time is so small which is negligible in our model, regardless of message consistency options.…”