Single file transfer

These tests were performed using a 1024 MB file for transfer of the hdf5 format. Without any network modifications or errors induced, the average file transfer time using Pushpull was ~332.416s which will be used as the reference figure (R1) in the discussion to continue. While the performance of the tool is evaluated, the capability of tool to deal with network modifications is studied here. The network was modified using the iproute2 package.

Constant packet delay

A constant packet delay was induced in the network using the following statement

$ tc qdisc add dev eth0 root netem delay 100ms

A minimal performance variation is observed for packet delays up to ~200ms, after which there transfer time increases accordingly. For the packet delays > 800ms transfer stalled and OODT generated the error message after which it continuously re-attempted to download the file:

org.apache.oodt.cas.protocol.exceptions.ProtocolException: Downloads appear to be
hanging . . . aborting wait . . . waited for 15 minutes

Packet drop/loss

$ tc qdisc change dev eth0 root netem loss 1%

Limited performance variation was observed for packet loss < 8% after which the transfer time significantly increased. For induced packet loss > 64%, PushPull generated the following error message:

org.apache.oodt.cas.pushpull.exceptions.RemoteConnectionException:
[ProtocolHandler]

Packet corruption

$ tc qdisc change dev eth0 root netem corrupt 1%

The packet corruption is not seen to have a significant impact on the performance of file transfer for packet corruption < 8%. For packets > 8% being corrupted, the file transfer time is seen to increase. For packet corruption > 32%, the terminal itself became unresponsive and incapable of testing file transfer using PushPull.

Packet reordering

$ tc qdisc change dev eth0 root netem delay 100ms reorder 1% 50%

This argument implies that 1% of packets sent will be reordered and delayed by 100ms with the next packet having a probability of 0.5 of also being reordered. The packet delay as well as the next packet being reordered probability were kept constant throughout the evaluation.

Packet reordering was found to significantly increase the file transfer time for packet corruption > 16% with a very surprising decrease in the transfer time for 32%. This behaviour was noticed for several test runs using the same parameter set.

Packet duplication

$ tc qdisc change dev eth0 root netem duplicate 1%

Although not a linear nor consistent increase in transfer time was found for packet duplication, an overall increase is marked. PushPull was found capable of dealing with great levels of packet duplication without stalling or terminating file transfer.

Modified TCP window

A single file of 1024MB was downloaded using PushPull using different TCP window sizes. There is the option to enable/disable TCP window scaling in the configuration file /etc/sysctl.conf and to set the maximum transfer window under LINUX. The file is then reloaded to update the parameters using

$ sysctl -p

The parameters in /etc/sysctl.conf which were modified are (e.g.):

net.core.rmem_max
net.core.wmem_max
net.core.rmem_default
net.core.wmem_default

A maximum transfer rate of ~20.1MB/s is achieved for TCP window sizes > 2048 Bytes. The smallest window size found for PushPull to be in an operational state was 256 Bytes giving an average transfer rate of ~11.2MB/s.

Concurrent file transfer

Modifying OODT thread number

The performance of OODT PushPull was evaluated for directory transfer using a directory structure of 16x1024MB binary files. This would result in an averaged outcome compared to single file transfer and also eliminating some anomalies which arose in some cases.

PushPull has the option of specifying the number of threads for download of multiple files in parallel e.g (/cas­pushpull­0.6/etc/push_pull_framework.properties):

org.apache.oodt.cas.pushpull.file.retrieval.system.recommended.thread.count=4

which will be used when the optimised variable is set to false:

org.apache.oodt.cas.pushpull.crawler.use.tracker=false

By manually setting the number of threads for concurrent file transfer, the optimised thread number was found to be 4 which was therefore used for further benchmarking of concurrent file transfer on a modified network.

Concurrent file transfer with packet delay

Using the recommended/optimised thread number for concurrent file transfer, the performance of PushPull is evaluated with induced packet delay into the network. While the bandwidth decreases for increasing induced packet delay, as expected, the tool is still capable of transferring files concurrently even with packet delays of ~1s (1000ms).

Concurrent file transfer with packet loss

Little or no performance variation was found for packet loss of < 4%. When a large percentage of packet loss was induced, > 16%, the transfer time was exponentially increased up to a point ( > 24%) where the tool was not capable of transferring.

Concurrent file transfer with packet corruption 

The performance of PushPull was found to drop to ~0.5 of the “clean network link” for a packet corruption = 24%. Beyond this point PushPull was not able to transfer files as the tool became unresponsive.