Start by using a monitoring tool to measure the actual performance you are getting. You might start with the built-in TCP Rate and Link Rate tools available under the Tool menu. If the measured performance is not up to what you expect for the kind of connection you have (dial-up, ISDN, cable modem, ethernet, etc.), it makes sense to do some detective work to determine if there is a problem and where.
Using the TCP Rate tool, you can actually observe how TCP/IP is working. Press the test button with or without specifying a "Test URL" to examine the pattern of data transfer. Is data flowing smoothly at close to the full bandwidth available or are there long pauses with no activity? You can use the data plot to look for excessive duplicate or retransmitted data (blue).
Do you see excessive packet loss and retransmitted data?
Is the client or server software limiting your performance? Try using a different client or server software package if possible.
Is your networking equipment configured properly (modem, ISDN terminal adaptor,...)?
If you suspect your system is not performing as well as it should, here are some examples of common tuning problems and solutions that may help.
Some cable modem connections use a telephone line for the uplink and are highly asymmetric (much faster downstream than upstream). The default network settings are not optimized for this. In particular, the TCP Receive Window size is too small so the sender quickly fills the "window" and then waits for notification that your machine is ready to accept more data.
To adjust the TCP Receive Window size, you need to set the "net.inet.tcp.recvspace". The idea is to make it big enough so it doesn't slow down performance, but not so big that it adds excessive latency or consumes unnecessary memory. The Link Rate tool can actually measure and calculate a recommended lower and upper bound for you. The default value in Mac OS X Panther (10.3) is 65536 which is a good starting point.
The TCP Rate tool in IPNetTunerX can be used to see the actual performance you are getting as you try different settings.
The MTU or Maximum Transmission Unit defines the largest segment or packet that can transmitted across a given network (without being split into smaller segments). For best performance, we normally want to use the largest packet size possible to reduce per packet overhead. The network stack in Mac OS X uses an automatic MTU discovery technique but it requires ICMP which some providers block or fail to support fully. If your network provider specifies a particular MTU as required, it will be more efficient and reliable to set this MTU explicitly.
In some cases, you may discover that connections fail unless you reduce the interface MTU. This is often the case for PPPoE which reduces the standard Ethernet MTU from 1500 to 1492 to accommodate an 8-byte PPP header.
It will be difficult to determine whether any changes you make actually improve network performance without some kind of network monitoring tool. You can sometimes learn a great deal just by looking at the pattern of data transfer in the TCP Rate window. IPNetMonitorX is a fairly simple and inexpensive monitoring tool that can provide a wealth of information. Other vendors including Neon Software offer more sophisticated measurement tools.
I have presented a one hour talk on Tuning Open Transport at recent Macworld/Pro Conferences which offers more detailed examples of network tuning. You can download the session slides here: "Tuning Open Transport" download as ClarisWorks, PDF
For more information on how TCP/IP works and TCP tuning parameters, may I suggest :
Mac OS X uses the Open Source BSD networking stack which is widely discussed on the web. You can often learn more about individual tuning parameters by searching the web for the corresponding parameter name. Appendix E of Stevens book "TCP/IP Illustrated", "Configurable Options" describes the tunable parameters available under traditional BSD stacks which are mostly the same as in Mac OS X. An updated version of this appendix is available from Stevens web page at:
This can provide a good starting point for understanding many of the tunable parameters you can set using IPNetTunerX. [Notice this is a Postscript file.]
I hope you find this information helpful.
- Peter Sichel
Previous | Next | Return to IPNetTunerX Help