GO IT WORLD | IT TECH | IT NEWS

Some of the diagnostic techniques described in the preceding section, "Testing Network Performance," suggest fixes for problems, such as contacting the operator of a router that’s not performing well or fixing a misconfigured /etc/resolv.conf file. This section covers three additional measures you can take to improve performance. Two relate to low-level TCP/IP settings. These values are normally set reasonably, so tweaking them won’t help in most cases, but it can help on some networks. The third option, running local servers, can improve performance when you rely on outside servers that you could as easily run closer to home.

Setting the MTU Size

Like most computer protocols, TCP/IP was designed with flexibility in mind. One negative consequence of flexibility is that when different systems implement a protocol using different defaults, the two systems may not interact as efficiently as when the two systems use the same defaults. One point of flexibility in TCP/IP is the maximum transfer unit (MTU) size, which is the maximum size of data packets it sends. You can learn the MTU for your system by using ifconfig:

$ ifconfig eth0 | grep MTU
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

This command displays the MTU, among other information. Ideally, all the computers on your LAN should use the same MTU. Linux’s default value for Ethernet networks is 1,500 bytes, and this value is common on many other OSs, as well. If a device on your network uses an MTU smaller than others, transfers involving that device may be slowed down slightly, particularly if the devices communicate through another device (such as a router). Such communication may require packets to be broken up. For instance, some ADSL connections use an MTU of 1,492 bytes, meaning that 1,500-byte packets must be split into two: one 1,492-byte packet and another 8-byte packet. If the originating computer had used a 1,492-byte or smaller MTU, the split wouldn’t be necessary. Of course, an 8-byte packet takes less time to send than does a 1,492-byte packet, so this conversion doesn’t double transmission time, but the extra overhead does degrade performance somewhat.

For the most part, MTU size isn’t a big deal in Linux, because Linux uses a technique known as path MTU discovery to determine the MTU on a site-by-site basis. If the initial MTU used for a connection is too high, Linux throttles it back until it works, thereby optimizing the connection. You can verify that path MTU discovery is enabled on your system by typing this command:

$ cat /proc/sys/net/ipv4/ip_no_pmtu_disc
0

A return value of 0 means that path MTU discovery is working; 1 means that this feature is disabled. You can use echo to copy a value into this pseudo-file if you want to change this option.

If you know that your system should use an MTU that’s smaller than it does by default, you can alter the MTU by using the mtu option to ifconfig:

# ifconfig eth0 mtu 1492

This example sets the MTU to 1,492 bytes, as might be appropriate if your system is on a LAN that uses an ADSL account with an MTU of 1,492. Setting this option in a startup script may slightly improve performance, even when your computer performs path MTU discovery; it won’t try a 1,500-byte MTU that’s destined to fail.

Setting the Send and Receive Window Sizes

A TCP data transfer isn’t a one-way affair; the sending computer sends data packets but expects to hear back from the recipient about the success of the data transfer. Suppose that these operations were to occur in serial—that is, the sender sends a packet, the recipient acknowledges receipt of the packet, and only then does the sender send a second packet. In this scenario, the transmission would be slowed down by the latencies involved in the connection. For instance, consider a 1Mbps connection with a 100ms round-trip latency and a packet size of 1,500 bytes. At time 0, the sender begins sending the packet. At 50ms (half the ping time), the recipient begins to receive the packet, but at 1Mbps, a 1,500-byte packet takes 12ms to arrive. Assuming an instantaneous response, that means the recipient can begin to send a response at 62ms. That response arrives at the sender’s system at 112ms. (The response is likely to be much shorter than 1,500 bytes, so we can assume it arrives much more quickly than 12ms.) If the sender can’t send a packet until receiving a reply, the sender will end up spending 12ms of every 112ms actually sending data, reducing the 1Mbps link to a 107Kbps (0.107Mbps) connection.

The solution to this problem is the negotiation of a receive window, which is the number of bytes that a system will accept before sending an acknowledgment, and a send window, which is the number of bytes it will send before requiring an acknowledgment. By setting these values high enough, you enable the sender to deliver data more-or-less continuously. Unfortunately, the optimum window size depends on the latency and throughput between the two computers—it should be at least as many bytes as your system can receive during the round-trip latency (that is, the ping time) between the systems. Table 1 summarizes the minimum window sizes you should use for different speeds and latencies. Entries in this table are derived from the formula size = bandwidth × latency, where size is the window size in bits, bandwidth is the throughput speed in bits per second, and latency is the ping time in seconds. (Table 1′s rows and columns specify latencies in milliseconds, throughput in megabits per second, and window size in kilobytes, though.)

Table 1: Minimum Send and Receive Window Sizes

Linux’s default window size is 64KB, which is enough for most connections. LAN speeds are off the chart as far as Table 1 is concerned, but consider a 100Mbps Ethernet network with 1ms latencies. The size = bandwidth × latency formula suggests a minimum receive window size of 12.2KB, so a 64KB window size is quite adequate. On broadband and other always-on Internet connections, latencies for connections on the same continent are usually 100ms or less, and connections seldom exceed 4Mbps. If your Internet connection is unusually speedy, though, you may want to consider a larger receive window size. Another extreme case is a satellite connection, which has very high latencies. Assuming a typical 500ms latency, a 61KB window size should be adequate for a 1Mbps connection.

If you believe your system’s performance is suffering because of a window size that’s too small, you can adjust it in either of two ways:

Using route Options  The route command adds routes to the Linux routing table. You can locate your system’s call to route (most likely in one of the scripts referenced in Table 1) and modify that call to include the window W parameter, where W is the window size in bytes.

Setting /proc Filesystem Options  You can set the default and maximum send and receive window sizes using entries in the /proc/sys/net/core directory. Specifically, rmem_default and rmem_max set the default and maximum receive window sizes, while wmem_default and wmem_max set the default and maximum send window sizes. For instance, typing echo "131072" > /proc/sys/net/core/rmem_max sets the maximum receive window size to 128KB.

In order to be effective, both your system and the one with which it’s communicating must support the larger size. For this reason, this adjustment may be ineffective if the remote system uses a 64KB or smaller window size.

Running Servers Locally

Accessing certain servers on the Internet at large is common, but running equivalents on your local network, or even on a workstation, can improve performance in some cases. Examples of servers you might want to run locally include:

Web Proxy Servers  A proxy server is a stand-in for another server; it accepts requests for data transfers, processes them partially, and passes them on to other systems. Proxy servers exist for many reasons, including security, filtering unwanted content, and improving speed. Speed improvements in web proxy servers derive from two factors. First, proxy servers can cache access requests, speeding up second and subsequent requests for a document. The Squid proxy server (http://www.squid-cache.org) exists largely for this reason. Second, a proxy that filters content can remove large images that can take a long time to download. Proxies designed to remove ads, such as Privoxy (http://www.privoxy.org), have this effect.

DNS Servers  Running your own DNS server can speed up DNS accesses for much the same reason that running a caching web proxy server can speed accesses.

Mail Servers  If you receive lots of e-mail from an ISP’s mail server, you may wait for it to download into your mail reader. You can use a local mail server in conjunction with Fetchmail (http://catb.org/~esr/fetchmail/) to speed up local mail accesses. Fetchmail can periodically retrieve mail and store it locally, so that you don’t need to wait so long when you load up your mail reader. The downside is that you won’t see any mail that’s arrived at your ISP between Fetchmail’s last run and the time you launch your mail reader.

News Servers  If you read Usenet news, you can run a local news server that does for news what the combination of Fetchmail and a local mail server does for e-mail. An example of such a program is Leafnode (http://www.leafnode.org). News servers designed for this purpose are much smaller than full-blown news servers. In some configurations, the local news server may download  much more data than you’ll ever read, but it will do so quickly, so the total time you’re connected to the news server can be much shorter than it might otherwise be. This approach is most appealing if you’re charged by the minute for your Internet connect time.

Warning

You should balance the benefits gained from running servers locally against the potential damage they might do. In some cases, the risk is very low. For instance, a server run behind a Network Address Translation (NAT) firewall is unlikely to be found and abused by an outside miscreant. If the system on which you run a server is directly exposed to the Internet, though, the risk of running such a server is much greater.

Random Posts

• 12/14/2010 -- PHP 5.3.3 GD extension imagepstext stack buffer overflow (0)
• 02/26/2010 -- Joomla Component com_joomlaconnect_be Blind Injection Vulnerability (0)
• 05/28/2011 -- sniffer tools example – 1 (0)
• 10/28/2010 -- Remove Duplicate Packages in CentOS (0)
• 07/25/2009 -- Microsoft to fix critical hole in IE (0)
• 10/02/2011 -- WordPress WP Bannerize plugin <= 2.8.7 SQL Injection Vulnerability (0)
• 07/18/2009 -- Top ten Passwrod Crackers (0)
• 08/27/2009 -- PHP Code Security Part 2 (1)
• 09/25/2009 -- Winplot (.wp2 File) Local Buffer Overflow Exploit (0)
• 03/13/2010 -- Cacti and MySQL counters problem (0)