Transport protocols and bulk file transfer

[Ezra Kissel <>]

http://www.reddnet.org/mwiki/index.php/BWC_results

These graphs are rather rough and don't show the best Phoebus 
performance due to a number of factors.  Principal among them is the 
fact that the current I2 Phoebus GWs cannot forward at more than 3-4Gb/s 
due to hardware limitations and therefore create a bottleneck for many 
of these 10G experiments.  Although we can effectively achieve 10G in 
the lab with more recent hardware, the reality is that we have to try 
and maximize the forwarding potential on the hardware available.  I have 
been working on some network receive splice improvements applied to the 
Phoebus code that should increase these hosts' forwarding capacity.  The 
initial results in using splice with Phoebus shows a significant 
reduction in CPU utilization by avoiding userspace copying of the data, 
and a subsequent performance improvement on CPU bound systems. 
Unfortunately, the splice implementation relies on recent changes to the 
kernel and will require an upgrade, with all the necessary testing, 
patching, and compatibility checks, on the currently deployed systems. 
I am hoping to evaluate the performance gains on Internet2 hardware soon 
and to eventually deploy the changes to the existing GWs, but this is 
expected to take some time to get off the ground.

More directly related to the REDDnet testing, we currently have 
dedicated access to a 10G Phoebus GW at SOX that has the potential to 
forward at much higher rates to and from the Vanderbilt REDDnet depots. 
 Networking for this GW should to be complete by next week after which 
I hope to get some improved REDDnet/Phoebus charts posted.

The best case for Phoebus in the above link are the CERN to UMich tests. 
 This involves a Phoebus GW at Amsterdam forwarding to a Chicago GW. 
Although the CERN->Amsterdam path is limited to 3Gig, Phoebus can 
provide substantial improvement over direct tests from CERN.

- ezra