TCPIP Stacks Network IO

- 312 -

14.4.1 Latency

Latency is different from the load-carrying capacity bandwidth of a network. The bandwidth refers to how much data can be sent down the communication channel for a given period of time e.g., 64 kilobits per second and is limited by the link in the communication chain that has the lowest bandwidth. The latency is the amount of time a particular data packet takes to get from one end of the communication channel to the other. Bandwidth tells you the limits within which your application can operate before the performance becomes affected by the volume of data being transmitted. Latency often affects the users view of the performance even when bandwidth isnt a problem. For example, on a LAN, the latency might be 10 milliseconds. In this case, you can ignore latency considerations unless your application is making a large number of transmissions. If your application is making a large number of transmissions, you need to tune the application to reduce the number of transmissions being made. That 10-ms overhead added to every transmission can add up if you just ignore it and treat the application as if it were not distributed. In most cases, especially Internet traffic, latency is an important concern. You can determine the basic round trip time for data packets from any two machines using the ping utility. [3] This utility provides a measure of the time it takes a packet of data to reach another machine and be returned. However, the time measure is for a basic underlying protocol packet ICMP packet to travel between the machines. If the communication channel is congested and the overlying protocol requires retransmissions often the case for Internet traffic, one transmission at the application level can actually be equivalent to many round trips. [3] ping may not always give a good measure of the round trip time because ICMP has a low priority in some routers. If, for instance, the round trip time is 400 ms not unusual for an Internet link, this is the basic overhead time for any request sent to a server and the reply to return, without even adding any processing time for the request. If you are using TCPIP and retransmissions are needed because some packets are dropped TCP automatically handles this as needed, each retransmission adds another 400 ms to the request response time. If the application is conversational, requiring many data transmissions to be sent back and forth before the request is satisfied, each intermediate transmission adds a minimum of 400 ms of network delay, again without considering TCP retransmissions. The time can easily add up if you are not careful. It is important to be aware of these limitations. It is often possible to tune the application to minimize the number of transfers being made by packaging data together, caching, and redesigning distributed-application protocol to aim for a less conversational mode of operation. At the network level, you need to monitor the transmission statistics using the ping and netstat utilities and packet sniffers and consider tuning any network parameters that you have access to in order to reduce retransmissions.

14.4.2 TCPIP Stacks

The TCPIP stack is the section of code that is responsible for translating each application-level network request send, receive, connect, etc. through the transport layers down to the wire and back up to the application at the other end of the connection. Because the stacks are usually delivered with the operating system and performance-tested before delivery since a slow network connection on an otherwise fast machine and fast network is pretty obvious, it is unlikely that the TCPIP stack itself is a performance problem. - 313 - Some older versions of Windows TCPIP stacks, both those delivered with the OS and others, had performance problems, as did some versions of TCPIP stacks on the Macintosh OS up to and including System 7.1. Stack performance can be difficult to trace. Because the TCPIP stack is causing a performance problem, it affects all network applications running on that machine. In the past I have seen isolated machines on a lightly loaded network with an unexpectedly low transfer speed for FTP transfers compared to other machines on the same network. Once you suspect the TCPIP stack, you need to probe the speed of the stack. Testing the loopback address 127.0.0.0 may be a good starting point, though this address may be optimized by the stack. The easiest way to avoid the problem is to ensure you are using recent versions of TCPIP stacks. In addition to the stack itself, there are several parameters that are tuneable in the stacks. Most of these parameters deal with transmission details beyond the scope of this book. One parameter worth mentioning is the maximum packet size. When your application sends data, the underlying protocol breaks the data down into packets that are transmitted. There is an optimal size for packets transmitted over a particular communication channel, and the packet size actually used by the stack is a compromise. Smaller-size packets are less likely to be dropped, but they introduce more overhead, as data probably has to be broken up into more packets with more header overhead. If your communication takes place over a particular set of endpoints, you may want to alter the packet sizes. For a LAN segment with no router involved, the size of packets can be big e.g., 8KB. For a LAN with routers, you probably want to set the maximum packet size to the size the routers will allow to pass unbroken. Routers can break up the packets into smaller ones; 1500 bytes is the typical maximum packet size and the standard for Ethernet. The maximum packet size is configurable by the routers network administrator. If your application is likely to be sending data over the Internet, and you cannot guarantee the route and quality of routers it will pass through, 500 bytes per packet is likely to be optimal.

14.4.3 Network Bottlenecks