Editing 3.1 UDP vs. TCP

Jump to: navigation, search

Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision Your text
Line 1: Line 1:
 
+
The [http://en.wikipedia.org/wiki/Network_File_System_(protocol) original NFS] used UDP [http://en.wikipedia.org/wiki/User_Datagram_Protocol UDP] for transmitting data for NFS.
== Background ==
 
 
 
The [http://en.wikipedia.org/wiki/Network_File_System_(protocol) original NFS] used UDP [http://en.wikipedia.org/wiki/User_Datagram_Protocol UDP] for transmitting data for NFS. UDP was chosen because is very simple, you are just transmitting packets and if they get lost everything is sent again. In addition, there is no load on the server when the connection to the network (or really the client) is not active. But UDP does have the problem that if the network has any congestion and packets are lost, all of the packets are retransmitted, increasing the load on the server and the network.
 
 
 
NFSv2, the original NFS that had widespread use, used UDP. A few companies put TCP into NFSv2, but it was not part of the NFS standard. With the advent of NFSv3 which was released around the mid-1990's, TCP was added to the protocol. Today, we can set our Linux NFS clients to accept data via UDP 9if we really want to) or to use TCP. The advantage in using TCP is that if a packet is lost, which can happen under reasonably heavy network congestion (or a bad switch), then only the lost packet is retransmitted, limiting the amount of data that has to be retransmitted.
 
 
 
 
 
== Recommendations ==
 
Getting the best performance using either UDP or TCP, really depends upon the situation. In general, people just use TCP because it's the default in most distributions (pretty much all distributions using a 2.6.x kernel).
 
 
 
 
 
=== Steps for Testing UDP and TCP Performance ===
 
But if you want to experiment, it is recommended that you start with UDP, run the cluster under load (i.e. run applications), and watch the load on the server as well as time the performance of your applications.
 
 
 
To test UDP, you have to modify the file, <tt>/etc/fstab</tt> on all of your clients (compute nodes). It is beyond the scope of this wiki to tell you how to modify the file on all of the compute nodes. Please consult the manual for whatever tool you are using. But the nfs mount points on the client should look like
 
<pre>
 
mount udp
 
</pre>
 
Don't forget to keep any options on the nfs mount points that you had before.
 
 
 
To watch the load, just use <tt>top</tt> (<tt>man top</tt> if you need help). Open a separate terminal on the node that is the NFS server and enter the command <tt>top</tt>. Then in another terminal window, run your application(s) on the cluster. Watch the load as the applications start - you can even record the peak load during the run.
 
 
 
When you run your applications, be sure you time how long they take to run. You can use the <tt>time</tt> command in front of your application. If you run your application as <tt>./foo</tt> you would run it as <tt>time ./foo</tt>. When the application is done, it will print out the real time, the user time, and the system time. You are interested in the real time.
 
 
 
After you test your cluster with UDP, test it with TCP.
 

Please note that all contributions to Cluster Documentation Project are considered to be released under the Attribution-NonCommercial-ShareAlike 2.5 (see Cluster Documentation Project:Copyrights for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. Do not submit copyrighted work without permission!

To protect the wiki against automated edit spam, we kindly ask you to solve the following CAPTCHA:

Cancel | Editing help (opens in new window)