|Home | GridMPI | GridTCP | Publications | Download|
Curret Release: GridMPI-2.1.3
English | Japanese
Overview of PSPacer
Precise Software Pacer (PSPacer) achieves precise network bandwidth control and smoothing of bursty traffic without any special hardware. Bursty traffic can degrade the communication performance, because it causes buffer overflow and packet losses in the intermediate switches or routers. PSPacer adjusts precisely the interval between outgoing packets, and it produces smoothed and stable traffic (see Fig.1).
In the past, some software-based pacing schemes have been proposed. However, they have been hard to implement, because they require that the operating system maintains a high resolution timer, which could incur lots of overhead. In contrast, PSPacer employs an alternative scheme which adjusts the interval to insert gap packets between outgoing packets. The form of gap packet is the IEEE 802.3x PAUSE packet, therefore gap packets are discarded at a switch input port and real packets go through on keeping uniform intervals.
PSPacer is implemented as a Linux loadable kernel module. It is independent of the device driver, and kernel re-compilation is not required for the installation.
For more information, you can see our publications .
Effects of PSPacer
To validate the effects of PSPacer on long fat pipe communication, we monitor TCP bulk traffic produced by iperf between two PCs which are connected via GtrcNET-1: programmable gigabit network testbed. In this experiment, the bottleneck link bandwidth is 500Mbps (62.5MB/s), the RTT is 200ms, and GtrcNET-1 emulates one TailDrop router whose buffer size is set to 4MB. In addition, FedoraCore 3 and the Linux kernel 2.6.11-1.14_FC3 (BIC TCP) are running on each PC which is comprised of two Intel Pentium 4 2.4GHz processors, 2GB of memory (DDR400), and an on-board Intel PRO/1000 GbE NIC (82545EM).
The following two figures show a bandwidth comparison with and without PSPacer. Here, the target rate of PSPacer is set to 500Mbps, i.e. the bottleneck link bandwidth. The blue line chart shows the average bandwidth with 200ms-resolution, and the red bar chart shows the finer-resolution (500us) bandwidth.
Without PSPacer, bursty traffic occurs over the bottleneck link bandwidth. Packet losses occur at about three seconds after the start, and then the sender shrinks the congestion window. The inefficient bandwidth utilization result in the poor performance.
With PSPacer, on the other hand, no packets are lost. And thus, the physical bandwidth of the bottleneck link is fully utilized, and then the communication achieves high and stable performance.
[Further Note] As shown in Fig.2.1, many SACK packets hang up the transmission for long period, because the stock kernel has a problem of the retransmission processing (see Here). So we applies a retrans hints patch which is based on the stuff included in Tom Kelly's Scalable TCP implementation. Fig.2.3 shows the improvement of the bandwidth restarting after many SACK packets. You can get the patch for linux 220.127.116.11 from here.
Please report problems to pspacer-users at m.aist.go.jp.
($Date: 2008-10-17 02:17:27 $)