UCL
 

Personal Miscellaneous TCP/IP GRID Quality of Service Multi-Cast

 
 

Loss and Performance Tests - 07 Feb 2003

Goal

The goal of this experiment is to determine the loss rates on the network by performing an active test for a long duration to determine the expected performance of the network.

This will be accomplished by performing a one hour long iperf udp test from mbng3 to gig6 and vice versa. Using the default udp configuration for udp packets (1470bytes udp) with a baserate (-b) of 2000m to ensure we are not limited by the software.

Both servers and clients were set up to report at an interval of every 1 second. This is to allow a timebased analysis of the performance of the udp stream.

Results

UCL to MAN

[ 3] 0.0-3599.7 sec 400 GBytes 955 Mbits/sec 0.009 ms 37572/292283937 (0.013%)

This shows the throughput in mbit/sec as reported by the iperf server at MAN for the udp stream (ignore the title, it's wrong). We can see that it's quite consistent, although the rate does drop every once in a while.

This shows the loss rates (in %) as a funciton of time. We loss rates of about 0.4%, with period loss of between 1.5 and 3%. Iperf summary states that we have lost only 0.013% over the hour. This equates to about 1e-5 loss. We are transferring just over 81,100 packets per second.

This graph shows the jitter of the udp packets as reported in iperf in ms.

MAN-UCL

[ 3] 0.0-3599.7 sec 400 GBytes 955 Mbits/sec 0.009 ms 37572/292283937 (0.0146%)

The throughput rate from MAN-UCL is comparable to that of UCL-MAN. The loss rates a slightly higher (0.0146 compared to 0.013). But everything else is comparable.

Looking at the profile of the loss rates; the loss appears to be not as frequent. However, the loss rates as a consequence are a lot higer - sometimes as high as 10%!.

Summary

The loss rates are higher than expected: 1e-5 is relatively high for a clean network. It is possible that this is due to host configuration problems. Tests from MAN to UCL shows very high loss rates of upto 10% for certain instances. This could be a buildup in local queues suggesting that packets would be dropped at the sender. Similarly the recv could be dropping the packets due to a flood of packets coming ing.

Suggestions:

  • repeat test with higher values of txqueuelen in /sbin/config on the senders.
  • conduct the test with two concurrent flows from two pairs of machines to check the loss rates. If they are the same, then it is likely a problem with the network; otherwise it is a host problem.

 

Wed, 23 July, 2003 13:07 Previous PageNext Page

 
 
    email me!
© 2001-2003, Yee-Ting Li, email: ytl@hep.ucl.ac.uk, Tel: +44 (0) 20 7679 1376, Fax: +44 (0) 20 7679 7145
Room D14, High Energy Particle Physics, Dept. of Physics & Astronomy, UCL, Gower St, London, WC1E 6BT