PFLDnet, Nara, Japan 2-3 Feb 2006, R. Hughes-Jones Manchester 1 Transport Benchmarking Panel Discussion Richard Hughes-Jones The University of Manchester then “Talks”

PFLDnet, Nara, Japan 2-3 Feb 2006, R. Hughes-Jones Manchester 2 Packet Loss and new TCP Stacks uTCP Response Function Throughput vs Loss Rate – further to right: faster recovery Drop packets in kernel MB-NG rtt 6ms DataTAG rtt 120 ms

PFLDnet, Nara, Japan 2-3 Feb 2006, R. Hughes-Jones Manchester 3 Packet Loss and new TCP Stacks uTCP Response Function UKLight London-Chicago-London rtt 177 ms Kernel Agreement with theory good Some new stacks good at high loss rates

PFLDnet, Nara, Japan 2-3 Feb 2006, R. Hughes-Jones Manchester 4 TCP Throughput – DataTAG uDifferent TCP stacks tested on the DataTAG Network u rtt 128 ms uDrop 1 in 10 6 uHigh-Speed Rapid recovery uScalable Very fast recovery uStandard Recovery would take ~ 20 mins

PFLDnet, Nara, Japan 2-3 Feb 2006, R. Hughes-Jones Manchester 5 MTU and Fairness uTwo TCP streams share a 1 Gb/s bottleneck uRTT=117 ms uMTU = 3000 Bytes ; Avg. throughput over a period of 7000s = 243 Mb/s uMTU = 9000 Bytes; Avg. throughput over a period of 7000s = 464 Mb/s uLink utilization : 70,7 % Starlight (Chi) CERN (GVA) RR GbE Switch Host #1 POS 2.5 Gbps 1 GE Host #2 Host #1 Host #2 1 GE Bottleneck Sylvain Ravot DataTag 2003

PFLDnet, Nara, Japan 2-3 Feb 2006, R. Hughes-Jones Manchester 6 RTT and FairnessSunnyvale Starlight (Chi) CERN (GVA) RR GbE Switch Host #1 POS 2.5 Gb/s 1 GE Host #2 Host #1 Host #2 1 GE Bottleneck R POS 10 Gb/s R 10GE uTwo TCP streams share a 1 Gb/s bottleneck uCERN Sunnyvale RTT=181ms ; Avg. throughput over a period of 7000s = 202Mb/s uCERN Starlight RTT=117ms; Avg. throughput over a period of 7000s = 514Mb/s uMTU = 9000 bytes uLink utilization = 71,6 % Sylvain Ravot DataTag 2003

PFLDnet, Nara, Japan 2-3 Feb 2006, R. Hughes-Jones Manchester 7 uChose 3 paths from SLAC (California) Caltech (10ms), Univ Florida (80ms), CERN (180ms) uUsed iperf/TCP and UDT/UDP to generate traffic uEach run was 16 minutes, in 7 regions TCP Sharing & Recovery: Methodology (1Gbit/s) Ping 1/s Iperf or UDT ICMP/ping traffic TCP/UDP bottleneck iperf SLAC Caltech/UFL/CERN 2 mins 4 mins Les Cottrell PFLDnet 2005

PFLDnet, Nara, Japan 2-3 Feb 2006, R. Hughes-Jones Manchester 8 uLow performance on fast long distance paths AIMD (add a=1 pkt to cwnd / RTT, decrease cwnd by factor b=0.5 in congestion) Net effect: recovers slowly, does not effectively use available bandwidth, so poor throughput Unequal sharing TCP Reno single stream Congestion has a dramatic effect Recovery is slow Increase recovery rate SLAC to CERN RTT increases when achieves best throughput Les Cottrell PFLDnet 2005 Remaining flows do not take up slack when flow removed

PFLDnet, Nara, Japan 2-3 Feb 2006, R. Hughes-Jones Manchester 9 Hamilton TCP uOne of the best performers Throughput is high Big effects on RTT when achieves best throughput Flows share equally Appears to need >1 flow to achieve best throughput Two flows share equally SLAC-CERN > 2 flows appears less stable

PFLDnet, Nara, Japan 2-3 Feb 2006, R. Hughes-Jones Manchester 10 Implementation problems: SACKs … uLook into what’s happening at the algorithmic level e.g. with web100: uStrange hiccups in cwnd  only correlation is SACK arrivals uThe SACK Processing is inefficient for large bandwidth delay products Sender write queue (linked list) walked for: Each SACK block To mark lost packets To re-transmit Processing so long input Q becomes full Get Timeouts Scalable TCP on MB-NG with 200mbit/sec CBR Background Yee-Ting Li

PFLDnet, Nara, Japan 2-3 Feb 2006, R. Hughes-Jones Manchester 11 TCP Stacks & CPU Load uReal User problem! uEnd host TCP flow at 960 Mbit/s with rtt 1 ms falls to 770 Mbit/s when rtt 15 ms u1.2GHz PIII rtt 1 ms TCP iperf 980 Mbit/s Kernel mode 95% Idle 1.3 % CPULoad with nice priority Throughput falls as priority increases No Loss No Timeouts uNot enough CPU power u2.8 GHz Xeon rtt 1 ms TCP iperf 916 Mbit/s Kernel mode 43% Idle 55% CPULoad with nice priority Throughput constant as priority increases No Loss No Timeouts uKernel mode includes TCP stack and Ethernet driver

PFLDnet, Nara, Japan 2-3 Feb 2006, R. Hughes-Jones Manchester 12 Check out the end host: bbftp uWhat is the end-host doing with your protocol? uLook at the PCI-X buses u3Ware 9000 controller RAID0 u1 Gbit Ethernet link u2.4 GHz dual Xeon u~660 Mbit/s PCI-X bus with RAID Controller PCI-X bus with Ethernet NIC Read from disk for 44 ms every 100ms Write to Network for 72 ms

PFLDnet, Nara, Japan 2-3 Feb 2006, R. Hughes-Jones Manchester 13 Transports for LightPaths uFor a Lightpath with a BER i.e. a packet loss rate or 1 loss in about 160 days, what do we use? uHost to host Lightpath One Application No congestion Lightweight framing uLab to Lab Lightpath Many application share Classic congestion points TCP stream sharing and recovery Advanced TCP stacks

PFLDnet, Nara, Japan 2-3 Feb 2006, R. Hughes-Jones Manchester 14 Transports for LightPaths uSome applications suffer when using TCP may prefer to use UDP DCCP XCP … uE.g. With e-VLBI the data wave-front gets distorted and correlation fails uConsider & include other transport layer protocols when defining tests. uUser Controlled Lightpaths Grid Scheduling of CPUs & Network Many Application flows No congestion Lightweight framing

PFLDnet, Nara, Japan 2-3 Feb 2006, R. Hughes-Jones Manchester 15 A Few Items for Discussion uAchievable Throughput uSharing link Capacity (OK what is sharing?) uConvergence time uResponsiveness urtt fairness (OK what is fairness?) umtu fairness uTCP friendliness uLink utilisation (by this flow or all flows) uStability of Achievable Throughput uBurst behaviour uPacket loss behaviour uPacket re-ordering behaviour uTopology – maybe some “simple” setups uBackground or cross traffic - how realistic is needed? – what protocol mix? uReverse traffic uImpact on the end host – CPU load, bus utilisation, Offload uMethodology – simulation, emulation and Real links ALL help

PFLDnet, Nara, Japan 2-3 Feb 2006, R. Hughes-Jones Manchester 16 Any Questions?

PFLDnet, Nara, Japan 2-3 Feb 2006, R. Hughes-Jones Manchester 17 Backup Slides

PFLDnet, Nara, Japan 2-3 Feb 2006, R. Hughes-Jones Manchester Gigabit Ethernet: Tuning PCI-X u16080 byte packets every 200 µs uIntel PRO/10GbE LR Adapter uPCI-X bus occupancy vs mmrbc Measured times Times based on PCI-X times from the logic analyser Expected throughput ~7 Gbit/s Measured 5.7 Gbit/s mmrbc 1024 bytes mmrbc 2048 bytes mmrbc 4096 bytes 5.7Gbit/s mmrbc 512 bytes CSR Access PCI-X Sequence Data Transfer Interrupt & CSR Update

PFLDnet, Nara, Japan 2-3 Feb 2006, R. Hughes-Jones Manchester 19 More Information Some URLs 1 uUKLight web site: uMB-NG project web site: uDataTAG project web site: uUDPmon / TCPmon kit + writeup: uMotherboard and NIC Tests: & “Performance of 1 and 10 Gigabit Ethernet Cards with Server Quality Motherboards” FGCS Special issue uTCP tuning information may be found at: & uTCP stack comparisons: “Evaluation of Advanced TCP Stacks on Fast Long-Distance Production Networks” Journal of Grid Computing 2004 uPFLDnet uDante PERT

PFLDnet, Nara, Japan 2-3 Feb 2006, R. Hughes-Jones Manchester 20 uLectures, tutorials etc. on TCP/IP: uEncylopaedia uTCP/IP Resources uUnderstanding IP addresses uConfiguring TCP (RFC 1122) ftp://nic.merit.edu/internet/documents/rfc/rfc1122.txt uAssigned protocols, ports etc (RFC 1010) & /etc/protocols More Information Some URLs 2

PFLDnet, Nara, Japan 2-3 Feb 2006, R. Hughes-Jones Manchester 21 High Throughput Demonstrations Manchester rtt 6.2 ms (Geneva) rtt 128 ms man03lon Gbit SDH MB-NG Core 1 GEth Cisco GSR Cisco 7609 Cisco 7609 London (Chicago) Dual Zeon 2.2 GHz Send data with TCP Drop Packets Monitor TCP with Web100

PFLDnet, Nara, Japan 2-3 Feb 2006, R. Hughes-Jones Manchester 22 uDrop 1 in 25,000 urtt 6.2 ms uRecover in 1.6 s High Performance TCP – MB-NG StandardHighSpeed Scalable

PFLDnet, Nara, Japan 2-3 Feb 2006, R. Hughes-Jones Manchester 23 FAST TCP vs newReno è Traffic flow Channel #1 : newReno è Traffic flowChannel #2: FAST è Traffic flow Channel #2: FAST Utilization: 70% Utilization: 90% 90%

PFLDnet, Nara, Japan 2-3 Feb 2006, R. Hughes-Jones Manchester 24 Fast uAs well as packet loss, FAST uses RTT to detect congestion RTT is very stable: σ(RTT) ~ 9ms vs 37±0.14ms for the others SLAC-CERN Big drops in throughput which take several seconds to recover from 2 nd flow never gets equal share of bandwidth