Sustainable Sustworks - Tools for Internet Travel
Inspired Tools for the Mac



Documentation and Examples

Easy Open Transport Tuning

The easiest way to tune Open Transport is to just double-click one of our preconfigured IPNetTuner documents. This will launch IPNetTuner, set up Open Transport, and quit. IPNetTuner does NOT have to remain running. It only needs to change designated Open Transport parameters. These changes remain in effect until the machine is restarted or further changes are made with IPNetTuner.

Use the document which is most applicable to your connection type.

You can also place a copy of this document in your Startup Items folder. Then each time your Mac restarts it will automatically be tuned.


Manual Tuning

You can manually tune individual Open Transport settings by launching IPNetTuner directly from the application.

The bar graph and the edit field immediately to the right of the parameter name shows the new value to be set when the Make Active button is selected. You can adjust the new value by editing the text field, clicking or dragging on the bar graph, or clicking the up/down arrows at the right top of the window.

For parameters representing time or a number of bytes, you can select the most convenient units by using the corresponding menu to right of the edit field.

For "Read Only" parameters that return a formatted report, the report is displayed in the text box immediately above the word "Status". Otherwise a brief description of the parameter is displayed.

The "Status:" field indicates the result of the last control operation (ioctl) used to get or set an internal OT parameter. If the status field reports that an unknown parameter name was ignored, this indicates the version of Open Transport on this system does not recognize the specified parameter. As Apple updates Open Transport, some tuneable parameters may be added or removed. If the status field reports that an unknown value was ignored, this indicates the value specified was outside the valid range for this parameter. You may need to select a smaller unit to specify a new value more precisely.

You can save any parameter settings you enter as a Tuner settings document. If the "Auto Configure" check box is selected, launching IPNetTuner from that settings document will automatically install the parameter settings you saved and quit the application. To restore your parameter settings each time your system is restarted, simply place the corresponding Tuner settings document in your Startup Items folder.


"Load Settings" - clicking this button will let you select a previously saved IPNetTuner document. These settings are only loaded into IPNetTuner. In order to invoke these settings you will also need to make them active.

"Load Defaults" - clicking this button will load the default Open Transport settings into IPNetTuner. These are the settings which are restored upon restart. In order to invoke these default settings you will need to make them active.

"Make Active" - clicking this button will send the settings loaded into IPNetTuner to Open Transport. You need to click this button to invoke any new settings (which could have been either manually set or loaded).




Actual Link Rate test to ISP's Name Server (cable modem service). Note the drop in raw IP throughput midway during test. This is where the ethernet interface MTU was set to 200 bytes (default is 1500). MTU was subsequently set to 4096 bytes, which demonstrated no improved throughput over the default setting.

The Link Rate test performs a general raw IP "throughput" test with any destination IP address (or domain name). Because this test measures the raw throughput of your Internet connection, it should always be the first test you run. You should expect throughput results which are in agreement with your overall connection speed. Hence, if you have a 56 K analog modem connection, and your ISP supports 56 K connections, then your Link Rate test to their DNS server or router should be about 56 KBits/sec (7 KBytes/sec). If you have a cable modem connection, you might expect about 1500 KBits/sec (188 KBytes/sec), or whatever speed your ISP has agreed to provide in your service contract. If your Link Rate tests are not up to par with what you are expecting from your service, then you may wish to contact your ISP.

This throughput test is based on sending echo-type ICMP packets of varied lengths to a single destination address and measuring the time for these packets to be returned. There will be some variability between test samples, so you may wish to run this test for a minute or two. Be aware, however, that you are repetitively sending ICMP packets to a working server or router, and you should not unnecessarily flood such servers with these test datagrams. Get enough information to clearly display your current Link Rate, then stop the test. The Link Rate test will automatically stop after 1000 samples have been acquired.

There are two very useful endpoints which should be used when performing a Link Rate test. The first is the Default Gateway endpoint. This is the router nearest to your machine (normally at your ISP's location) and a measurement of the throughput to this endpoint will give you a very good estimate of the maximum throughput you should expect from your Internet service. Just select the "Default Gateway" option in the Local Targets popup menu and the default Gateway IP address of your machine will appear in the proper edit box. You can then test using this IP address. Note: if you are using a hardware NAT router to share your Internet connection, you should actually use the router address is which is serving the NAT router, and not the NAT router address itself (the latter will only measure your local ethernet speed). In this situation, you can readily determine your ISP's router by doing a trace route with our IPNetMonitor tool. The second router in the the trace listing will typically be your ISP's router (it normally will NOT have a 192.168.x.x nor a 10.x.x.x type IP address).

If you are using a PPP connection, you should use the "Connected To:" IP address as displayed in the Remote Access control panel.

The other useful endpoint to test against is your ISP's DNS (domain name server) IP address. This address is the second option in the Local Targets popup menu. Again, this should be quite an accurate Link Rate test since this server is in the control of your ISP and should be located on their backbone.

It is recommended that you use either of the above IP addresses when measuring your raw IP throughput with the Link Test.

There are very few Open Transport parameters which can be modified and improve your raw IP throughput. One important parameter, however, which you can modify is the interface MTU. When changing the ip_interface_MTU value, you must first select the active interface (port) from the popup menu. Then you can modify the ip_interface_MTU value. After making any changes to this value you must click the "Make Active" button to actually invoke the changes. In most cases the default MTU settings are going to give you a raw throughput that is as good as you can expect. With PPPoE connections, you may have to be careful about modifying the ip_interface_MTU value because this may completely disrupt PPPoE.

You can also perform link rate tests with any other servers on the Internet, and these can be useful link rate tests if you suspect that there is some bottleneck in a router along the path. Just be aware that there can often be dozens of routers between your machine and the final destination IP address. In general, distant IP address tests do NOT make good Link Rate tuning tests. You are much better off performing your Link Rate tests with a local router or server.


Actual TCP Rate test to "". Baseline established with default OT parameters. Improved performance based on loading and making active the "Cable/DSL/ADSL" settings. Baseline throughput was 81 KBytes/sec, improved throughput was 128 KBytes/sec (60% improvement).

The TCP Rate test performs a HTTP-type (browser) page download test using a remote server. This is a more "real world" test since it uses the same type of download process which you use during browsing and file downloading. Basically you enter a web site name (or a complete URL) with which you want to test against, and click the "Test" button. IPNetTuner then contacts the server. When data starts arriving, an internal clock is started. When the page is finished loading, the clock is stopped. The number of bytes downloaded is divided by the elapsed time giving a download rate (bytes/sec). This page download sampling is repeated over and over.

For TCP Rate testing you should choose a web server which meets the following criteria:

  • returns a page larger than 20 KBytes (you can enter any valid page from a site). This will ensure enough sample data is acquired over several packets in order to obtain a good measurement.
  • is not limited by the CPU of the server (i.e. you don't want to test against an overloaded server).
  • is not limited by a throttled connection (some servers work on shared and bandwidth limited connections. This is especially true of virtual hosts).

Good choices are often major corporation sites such as,,, etc. Note that you should limit your testing on these servers since you are placing a load on them. Get enough data to view your results, then stop the testing. Testing is automatically limited to 1000 trials.

A good way to perform TCP testing is to click the "Load Defaults" button then the "Make Active" button. Then enter the site (or URL) of interest and click the "Test" button. This will give you a baseline. You will see the results of the TCP test. Acquire enough data to establish your baseline for this page.

You can then manually tweak specific settings OR load a preconfigured group of settings. Then click the "Make Active" button to invoke these new settings. Note the graph. This will give you clear indication if the Open Transport setting changes had any affect.


"Test" - clicking this button will start the Link Rate or TCP Rate test. This button changes to "Stop" when the test is running and clicking it will stop the test.

"Clear" - clicking this button clears the display and resets the averages.

"Reset" - clicking this button resets the averages.

"Mark" - clicking this button establishes a baseline which is displayed in red on the graph. It is actually the current Byte/sec average at the time the button is clicked.


Commonly Modified Parameters:

For ALL connections:



Specific Cable/DSL/ADSL Connection Settings:



Specific PPP Analog Modem Connection Settings:



Read Only Reports:

arp_cache_report (low level ARP cache)
ip_ill_status (ip lower layer physical interfaces or link streams)
ip_ipif_status (ip logical interfaces)
ip_ire_hash (ip routing table)
ip_ire_status (internet routing entries)
tcp_status (connection list)
udp_status (open endpoints)


More on TCP/IP Tuning

For more information on how TCP/IP works and TCP tuning parameters, we suggest :

  1. "TCP/IP Illustrated, Volume 1" by W. Richard Stevens;
  2. "Tuning Open Transportt " document (based on Peter Sichel's talk given at MacWorld).
  3. "Tips for TCP/IP monitoring and tuning to make your network sing", by Adrian Cockcroft.
  4. "Solaris - Tuning Your TCP/IP Stack"
  5. "Solaris Tuneable Parameters Reference Manual"

Open Transport is very similar to Solaris networking since both are based on Mentat/TCP.


Implementation Notes

IPNetTuner sends an I_STR ioctl command to get/set the specified parameter name and value from/to the "Named Dispatch" facility of the corresponding module (TCP, UDP, or IP). Any TCP or IP "Named Dispatch" parameter can be added by editing the 'OTip' resource.

Although kernel parameter settings can be changed at any time, some settings will not take effect until the next instance of TCP is created.

IPNetTuner "settings documents" are simple text files you can easily edit. Here's an example that performs the same function as the "OTTCPSlowLinkTuneup" patch that was distributed a while back. Any parameters not in the file are set to their default values.


It is easy to write OT Advanced Tuner scripts by creating a settings file and sending an Open Document Apple Event to the application with signature 'OTat' (OT Advanced Tuner).

Extending IPNetTuner

The parameters that can be examined and modified by the IPNetTuner are specified as resources of type 'OTip' (OT internal parameter - starting from resource ID 201 and up). The 'OTip' resource may be edited using the supplied resource template. The resource name corresponds to a Named Dispatch (ND) parameter name. The resource data consists of four 32-bit values for the min, max, and default parameter values, and a unit code that identifies the parameter units.

<32-bit min>
<32-bit max>
<32-bit default>
<32-bit unit code>

Common Unit Codes

const kUnitNone            = 0;
const kUnitNumber          = 1;
const kUnitOnOff           = 2;	! 0=off, 1=on
const kUnitBytes           = 3;
const kUnitMilliseconds    = 4;
const kUnitPercent         = 5;

A text description of each parameter is stored as a 'TEXT' resource with the corresponding resource ID.

Tuner Settings Files

Tuner settings documents are plain text files defined as follows. Each line of the file ends with a CR ('\r') and is interpreted based on the first character of the line:

#   A command keyword follows.  The only keywords currently
    defined are "auto" for Save-As-Auto-Configure, and "end"
    for end-of-data.
a-z The start of a name-value pair in the format
    <paramName>=<paramValue>.  Only recognized
    parameter names are accepted.

Any other starting character will cause the line to be skipped as a comment.

Example Tuner File:


When setting the MTU, it is necessary to specify the interface name on a separate line (since each IP interface can potentially have its own MTU - notice you can only set the MTU for one interface per command file). The easiest way to determine the correct interface name is to edit a saved OT Advanced Tuner settings document. Open Transport interface names can also be determined from the Interfaces window in IPNetRouter.