Personal Miscellaneous TCP/IP GRID Quality of ServiceMulti-Cast  
Background high-speed tcp Transfer Tests Web 100TCP Tuning  

Back 2 Back UDP Tests

Method

Each test was conducted 5 time. Each test consists of sending 1 million udp packets from one machine to another using udpmon (v3.1d3). Udpmon was configured to report the one way delays and differences between the sender and recv times.

Results

Results: xls tvs

The above graph shows that the udp data rate throughput does not change much for the range of txqueuelen values under investigation. There is some variation; most probably due to losses:

This graph shows the per centage loss of the million packets. Surprisingly there relatively high losses, considering it is back to back. It appears as though to minimise losses, it is best to implement a txqueuelen of between 10 to 100.

The above graph shows the cpu free usage of the udpmon server and client. This implies that both sender and recv took about 23% CPU to send at the rates above.

The above graph shows the amount of time it takes for the sender and recv to send and recv each packet. There is very little difference, implying that both the sender and recv are operating comparative.

This graph shows the updmon reported mean and median values.

The above shows the skew and sigma values as reported by udpmon.

This shows the differences of the sending and recving timestamps. It is pretty consistent throughout all txqueuelen values.

The One Way Delay, as reported by udpmon, is also pretty constant throughout the sample range of txqueuelen. This implies that there is negliable added latency in increasing the txqueuelen size.

 

Wed, 23 July, 2003 13:17 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