On Improving Open Transport Network Application Performance

Other Tips

 There are a few other points that you should be aware of to get the most out of Open Transport in your network server design.

Using the Native OT API Rather Than MacTCP

There is no excuse for your server application not to use the native OT API. Here are some of the reasons why: check this...

But for servers, the primary reason to use the OT API is performance. For example: Experiments using the Spud test tool over Ethernet on 68K systems have yielded a throughput of somewhere between 300-400k bytes/sec using MacTCP vs 600-800k bytes/sec using Open Transport. On the PPC, the numbers are much more impressive, easily saturating the 1 Mb Ethernet speed.

Preliminary tests indicate speeds approaching 90% link utilization ATM.

Provider & Client Events

To survive port switching such as PPP etc, the server should handle provider events such as kOTProviderWillClose

use the OTRegisterAsClient to gather client events such as kOTNewPortRegistered, kOTPortOnline

Tuning Server Memory Allocation

Another option for improving server performance is to modify Open Transport's memory allocation limits. If you intend for your server application to run on a dedicated Macintosh, this is an effective way to ensure that enough buffer space is available to maintain a high transaction rate.

Starting with version 1.1.1, you will be able to use OTSetMemoryLimits to direct Open Transport to grow its internal client memory pool. You should use this API instead of the OTSetServerMode. OTSetMemoryLimits takes two arguments, a size to grow now and a maximum limit to expand the memory pool.

Developers should be aware that the use of OTSetMemoryLimits will require some experimentation on thier part to determine optimal values for a given application.

Remember to call OTSetMemoryLimits(0,0) before quitting your server to inform Open Transport that specialized memory requirements are no longer required.

The prototype for OTSetMemoryLimits is not currently available in the "Open Transport.h " include file. You should use the following: 

	  extern  OSStatus OTSetMemoryLimits(size_t growSize, size_t maxSize);
Warning:
Although currently available, you should be aware OTSetServerMode and OTSetMemoryLimits may not be supported the future versions of Open Transport. To be sure, check with Apple Developer Technical Support.

OT Servers and Power Management

For performance reasons Open Transport maintains it's own set of counters to handle power management. These counters are used to call IdleUpdate() when appropriate network activity is present.

Counters are reset OTSnd, OTSndUData, OTRcv, OTRcvUData is called.

App has to read data for counters to prevent sleep.

Pinging a node won't prevent sleep.

Sleep vs Power down

We are writing an application that requires us to connect to a remote machine via TCP/IP and talk to a background application running on that machine. However, we are cannot connect to that machine when it is in the sleep mode. Is there a way to keep the network services alive when a machine is in sleep mode? I have seen how you can keep the serial port alive, but not the network services.

When a machine such as a powerbook goes into the "Sleep" state It is incapable of responding to network requests. This is true because the connections actually shutdown. There are some macintosh machines that attempt will go into an energy efficient mode know as "doze".

The Sleep state is easy to prevent and is pretty well documented in the Power Manager chapter of Inside Mac: Devices under "The Sleep Queue" and "Sleep Procedures", and there is some more information TN 1046: "Inside Macintosh: Devices-Power Manager Addenda"

Assuming that you want to prevent the system from sleeping or dozin you would:

1) allocate a SleepQRec (preferly in system heap)

2) set it up to call into your sleepHandler.

3) THen when the Mac attempts to sleep or doze, it will call your sleepHandler with a sleepRequest or dozeRequest selector.

4) to prevent sleep from occuring you simply return a nonzero value.

In the doze state, OpenTransport networking is still enabled and TCP connections that are setup should still function. BUT it might take several packets recieved withing a short period (like 10/sec) to wake the machine from it's doze state.

You might consider hiting your network listener with a short barrage of packets. Or pinging the machine first to get it out of doze. Either way, you should be aware that it will take some time for the networking to reactivate, especially if Virtual Memory is enabled and the disk drive must spin up.

There is also some information on controling the Energy Manager in TN 1086: Power Management & The Energy Saver API". You can find these at

Server Shutdown

Server developers typically neglect to handle issues related to quitting their applications. To shut down an Open Transport network server properly, you need to be sure that your application performs the following items:

TimeStamp

Open Transport provides a number of time stamp functions such as OTGetTimeStamp that can be used to accumulate profiling information. These functions are fast, and safe to call at Primary Interrupt time. You can use this time stamp information later to identify bottlenecks or report on application performance.

Protocol Specific Issues

Depending on the provider and the version of Open Transport that you are using there are specific optimization and techniques that you should be aware of that be applied to enhance server performance. The best source for this information is the Open Transport Client Developer Note or the Open Transport Release Notes. You should also check the Apple Open Transport Website for the latest information.

AppleTalk and ADSP

All the topics addressed in this Technote also apply to ADSP & PAP.

OT 1.1.2 addresses PAP server problems?

[Prev] p. 1 2 3 4 5 6 7 8 [Next]