|
|
|
Network Performance ConsiderationsThese are my own ruminations on Network Performance Considerations around which questions seem to arise frequently. I have attempted to write some intelligible words in an effort to help clarify the situations. Emphasis on attempted.NB. Everything on this page is in preliminary draft form! Please bear that in mind and feel free to send comments to me. Thanks.
PerformanceThis issue often arrises when someone with a "fast" network connection does not get the download speed that they expect. This happens in corporate LAN environments as well as in homes with Cable Internet or xDSL Internet access. The expectations are driven by advertized access speeds or link rates. In the corporate environment Wide Area Networks (or WANs) have traditionally been relatively low speed. What that meant was users pushed their data into a low speed pipe and recognized that the low speed connection took some time to send and receive data. Home users traditionally had low speed dial-up access if anything with the same sort of expectations. With the advent of high speed internetworking (e.g. ADSL at home, and 10 or 100 Mbps WAN services available for business) the expectation was set that performance would jump. However, there are some inherent limits that must be considered. A number of different limits come into play when packets need to travel significant distances that may not be apparent on a local LAN. Light Speed!Although it may seem that the speed of light is so great that it should not be a consideration, however de facto, it is. The speed of light is commonly quoted as being close to 300,000 km/second. What is often omitted is that this is the speed of light in a vacuum. Without embarking on a massive dissertation on the subject, let us simply accept that the refractive index of the medium through which light travels affects the speed of light in that medium. The reason I mention this is that for networking purposes, where necessary, we will consider the speed of light in glass (fibre). Without proof, I will submit that it's speed is close to 200,000 Km/second in fibre. Why do we care? In a likely network situation, the path from New York to LA (for example) will likely involve about 4,800 Km of fibre. It will take light, travelling in fibre, about 24 mS to traverse that distance. As we will see later, this "network latency" will affect the maximum performance that we can get out of the network that we have in place. In fact, it is usually the round trip delay which acts as a limit for performance. Hence in our example above, 48 mS. When looking at the performance model below, compare the maximum levels of performance achievable on a LAN where latency is very low ( ~1 mS) with the performance limit imposed by the speed of light. The results may surprise you. TCP/IP LimitationsTCP/IP implementations typically have a limit on the maximum throughput possible from a station. Why? Simply because the TCP/IP stack has a maximum outstanding amount of data that can be in transit from one point to another without acknowledgement of delivery. In Basic TCP, the maximum number of bytes that can be in transit (specified by the TCP receive window size) is limited to 64KB by the 16 bit window size field in the TCP header. Often the 64KB value is used to illustrate the maximum theoretical throughput of TCP. This is only partially true. Actual implementations of TCP/IP usually have either 8KB or 16KB limits. In the early 1990s Van Jacobsen et Al. recognized that higher bandwidths were becoming available and that TCP needed to be updated to support high bandwidth, high latency networks. The work culminated in 1992 with the publication of RFC 1323 which specified modifications to TCP to support the high bandwidth, high latency networks. This removed the 64 KB limit, in theory. In practise, as mentioned above, most TCP/IP stacks run with an 8 KB maximum window size (Linux, Windows 9x, Windows NT, etc.). Although some operating systems support the RFC 1323 extensions, they are not typically enabled in the default installations. Windows 2000, for example has a 16 KB maximum receive window size, but supports the RFC 1323 extensions by means of Registry entries (disabled by default). Various flavours of UNIX require that the Kernel source code be modified and then recompiled before the default window size can be changed. Furthermore, most Linux distributions require that the changed window size remain 32 KB or smaller due to variable typing in the source code. Simplified TCP/IP on Ethernet Performance ModelI have prepared a Microsoft Excel spreadsheet to illustrate the maximum possible throughput of TCP/IP as it varies with the round trip latency between sending and receiving stations. Latency and Window size turn out to be the key factors determining the Maximum TCP/IP throughput. As an example, with an 8 KB receive window, a west coast Linux user in the USA downloading a large file from an east coast server will probably see a limit of 1.1 Mbps in the transfer given a 60 mS round trip network latency, regardless of the available bandwidth! Take a look at the spreadsheet. Or as a web page. Something is still not right You've looked at the numbers and your application performance is way below expected levels. What else can be happening?
Firewalls. Are there any firewalls between the two endpoints? Half Duplex Ethernet (IEEE 802.3)Since Ethernet is the most common networking platform on which people usually use TCP/IP, it's characteristics are worth consideration. What's better, a half duplex 10Mbps Ethernet connection as an access technology to the Internet and your WAN or a T1 based service at a lower cost? It is commonly argued that the fact everybody knows is that half duplex Ethernet saturates at 3.0 Mbps and T1 gives you 1.5 Mbps in each direction. Ergo 3.0 Mbps. On the surface, the T1 seems like a better deal. Is it? Lets take a closer look. The common myth about half duplex Ethernet is that it saturates at 3Mbps of traffic, so a full duplex T1 at 1.5 Mbps in each direction sounds like the same performance. Is this true? Not really. In the worst case, using the maximum number of repeaters, the longest permissible cable runs and maximum number of stations on an Ethernet, it can be as poor as 3Mbps. What does length have to do with it? Time. The amount of time that it takes to detect a collision. The collision needs to propagate from the place it occured to the furthest atation on the segment. The longer the segment the more time it takes.The more time that is wasted by collisions the lower the useable bandwidth becomes. What does the number of stations have to do with it? Same thing. The more workstations there are, the more time gets wasted by collisions. In any current practical implemetation of the access technology, the only half duplex portion is the interface from the provider's router to your Ethernet switch. Maybe twenty feet and only two nodes. What does this mean? Any collision that occurs will actually be detected almost the instant that it happens. That means that less time is wasted, and consequently less bandwith, due to collisions. In practise almost a full 10 Mbps of bandwidth is useable on such a channel. Additionally, the full 10 Mbps of capacity is available for unidirectional traffic. In a typical Internet access scenario, most of the traffic is inbound (consumption) from the Internet. In this situation, a full 10 Mbps is available for download where in a T1 based service only 1.5 Mbps can ever be tapped for this purpose. See the definitive work on the half duplex Ethernet Capacity topic done at DEC Western Research Labs in 1988. Full Duplex Ethernet, Measuring Bandwidth, PathChar and other thoughtsFull Duplex EthernetWhy is my new Full Duplex Ethernet service no faster than the half duplex version was?! It is, but measuring it becomes more interesting. Testing from a single workstation by using Van Jacobsen's Pathchar or by doing a file transfer timing test will basically give you results similar to what you had for half duplex since the information transfer is uni-directional. Try simultaneous file transfer timings in both directions and compare those results with the half duplex tests of the same type. Are the numbers still low? What is the network latency between the two hosts in the test? Is the TCP/IP window size issue above playing a role? PathChar ... What is PathChar? How does it work? PathChar is a network utility program that attempts to determine bandwidth on a link by measuring the round trip times (RTT) using various sizes of packets. Things to remember using Pathchar: It tries to estimate available bandwidth. Using it on a production network will never give you an accurate measure of the link speed because it is in use! If you can test at a time when you know that the network is completely inactive, you stand a better chance to see accurate results. Otherwise, bear in mind that existing network utilization will reduce the estimate that Pathchar returns! Using Pathchar on ADSL / Asymetric Loads Since PathChar uses round trip times (RTT), if you're attempting to characterize an ADSL link or a link that is in use for web browsing, you need to realize how the round trip times will be affected. PathChar assumes that the RTT is the sum of the values of the two SYMMETRIC one way delays. If the network you are characterizing is an ADSL link or if it is loaded with web browsing traffic (which is asymetric by nature), the net result is that the two one way delays are NOT equal. Results of PathChar (or any bandwidth characterizing tool) will most likely be inaccurate at least on the link in question. For links beyond, the results are at least a little uncertain. NOTE: One empirical study showed that on average, for a network with a high proportion of web browsing traffic, the volume of inbound traffic was 5 times that of the outbound traffic. More Pathchar notes. Other Tools PCHAR by Bruce Mah, an updated Pathchar ... File Transfer Timings and other tests ... Remember that any test you try will be subject to the TCP/IP window size issue and to competition with other traffic on any and all intervening links between the two (or more) hosts participating in the test. I know this sounds obvious, but it can easily be forgotten in the heat of the moment!
|
