Managing Bandwidth

Analyzing Network Performance

The transfer of data between computers across a network involves the interaction of dozens, sometimes thousands, of hardware and software devices.  Any one of these may have a substantial impact on the performance of either TCP/IP or MTP/IP.  This document describes some of the more common factors which are known to have a significant impact on performance.  Where possible, suggestions for improving performance are also given.

While many factors may influence performance, at any given time there is likely to be one which directly affects the result .  This is called the "limiting" factor because it determines maximum speed at which the network can perform under the circumstances.  Identifying the limiting factor in any given case is vital to improving performance.

Note that the limiting factor may change with time or in response to changes in other factors.  For example, during peak usage hours, Third Party Traffic may be the limiting factor.  At other times when the network is idle, the Maximum Path Speed may limit how fast data can travel.  As you will see from the descriptions that follow, some factors affect TCP more than MTP and some factors affect MTP more than TCP.  Thus, changing network conditions may affect their relative performance.  It is therefore important to both test under a variety of conditions, and useful to have a strong understanding of the conditions in which your data transport functions will be performed.

Testing Tips

When evaluating any technology, it is important that your tests come as close as possible to recreating the conditions in which the technology will actually be used.  Ideally, you should run the test applications on the same systems and under the same conditions where you are currently using TCP or plan to use MTP.  Even if the test conditions appear to be very similar to the intended use conditions, there are certain caveats which can affect the results.

Disable TCP acceleration devices

You may already be using a hardware or software device to "accelerate" your network.  Such systems may be configurable to work with MTP, but for test purposes disable third-party acceleration devices.  You can re-enable them later once you have established a baseline of performance.

Configure Firewalls, NAT, and VPN Devices

Firewalls, NAT gateways, and other devices designed to interfere with network traffic may block or degrade MTP/IP applications.  See technical note 0002, "Configuring Firewalls" for instructions.

Measure Time Independently

Many FTP and HTTP clients (especially Internet Explorer) are very "optimistic" when reporting transfer speeds because they only report during bursts of data arrival and don't count the times when TCP is stalled.  For the most accurate results, measure the time it takes to transfer data using a stopwatch or a command line utility such as "time".

Test Different Times and Different Paths

TCP is very sensitive to the type of network being used and the patterns of traffic present.  Its performance will vary between different sites and throughout the day and week.  For the most complete picture of how MTP and TCP compare, try as wide a variety of tests sites and times as possible.

Factors Affecting MTP/IP Performance

The following factors affect MTP/IP directly, and will therefore affect all MTP/IP applications.  You can isolate MTP/IP factors from application factors by using the MTP Test utility, which is available for download from the DEI support website at http://www.DataExpedition.com/support/.

Maximum Path Speed

MTP cannot move data faster than the underlying network hardware.  When hardware is the limiting factor, MTP will not provide a throughput improvement, but will still provide a transaction speed improvement.  Note that the maximum path speed is the actual maximum throughput of the slowest link between two computers.  Very often, hardware such as DSL lines and WiFi, or services such as Virtual Private Networks, are rated at speeds much higher than they actually deliver.  Determine your actual path speed before evaluating any performance options.

TCP Relative Speed

TCP's performance may vary substantially due to many factors, including the time of day.  If TCP is operating close to the Maximum Path Speed, then MTP may not offer faster throughput than TCP, because no transport protocol can be faster than the network itself.

Operating Systems

Different operating systems handle networking in different ways.  Windows is very different from unix systems.  The choice of system also affects how other factors such as CPU Load, Memory, Disk Speed, and Local Link Speed will affect each protocol and application.

CPU Load

A high CPU load will affect both TCP and MTP performance.  Depending on the Operating System, type of software running, and many other factors, one protocol may be affected more than the other.  Using a faster processor and running fewer other applications may improve network performance for both protocols.

Third Party Traffic

MTP and TCP must compete with other users of the network.  As more people use a network path, performance for all users will decrease.  This is especially true if the Maximum Path Speed is the limiting factor.  TCP becomes very inefficient when third party traffic is high, causing TCP to consume large amounts of resources while providing poor performance.  MTP will show the largest relative performance improvement at times when third-party traffic is high.  The degree to which MTP impacts to third-party traffic can be increased or decreased..

Idle Latency (Round Trip Time)

The time it takes for a very small amount of data to travel between computers and back again is called the Round Trip Time (RTT).  Rising RTT is indicative of heavy network use.  If RTT is high (over 500ms), TCP performance will often be poor and MTP performance relatively good.  If RTT is very low (under 10ms), TCP performance may be limited only by the Maximum Path Speed.  MTP can be configured to limit its effect on RTT.  See each application's documentation or contact DEI for details.

Factors Affecting ExpeDat Performance

The ExpeDat application is normally used to transfer files stored on the hard drive of one computer to the hard drive of another computer.  End-users may interact directly with ExpeDat, particularly the graphical client.  These functions may have an impact on data transport performance.  Note that ExpeDat will generally provide better performance than HyperGate.

Disk Speed

ExpeDat cannot move data faster than the hard drives can read or write the data.  If the performance is being limited by disk access, ExpeDat will also be limited.  Disk speed is affected by the choice of hardware and operating system.  Other applications accessing the disks at the same time may substantially degrade performance.  Disks mounted over a network will be substantially slower than disks mounted directly on the CPU.  If you are transporting data on a 100 megabit per second or faster network, investigate disk performance before evaluating network performance.

Memory Cache

Most operating systems will use a portion of main memory (RAM) to store data that has been recently read from or written to disk.  This can reduce the affect of Disk Speed and substantially increase performance.  Increasing the amount of available memory may increase performance.

Encryption

Encrypting and decrypting data requires several times more CPU processing on both the client and server.  If the CPU load is the limiting factor, turning off encryption may improve performance.  Note that ExpeDat always encrypts usernames and passwords, even if content encryption is turned off.

Packaging

If server-side packaging utilities are used, ExpeDat will be unable to move data any faster than those utilities deliver it.  Likewise, if the client-side output is piped to another application, ExpeDat will be unable to move data any faster than the other application can process it.  Packaging will greatly increase CPU and memory requirements, which may also affect performance.

Factors Affecting HyperGate Performance

The HyperGate application uses MTP/IP to move data between a TCP/IP based web server and a TCP/IP based web browser.  To do this, HyperGate must establish TCP/IP connections to the server and browser at both ends, then copy the data between TCP/IP and MTP/IP.  This introduces several additional factors which may affect performance.

Maximum Web Server Throughput

HyperGate cannot move data faster than the Web Server sends it.  If the web server is configured to limit the rate at which it sends data to hgserver, this will limit the rate at which HyperGate can move the data.  Be sure that the web server is not limiting the rate at which it delivers data to hgserver.

Web Browser Efficiency

HyperGate cannot move data faster than the client's Web Browser receives it.  Some browsers are not efficient at reading data and may force hgclient to pause and wait for the browser to be ready.  Use of a "faster" browser may be needed.

HyperGate Overhead

HyperGate must copy data from TCP to MTP at the server side, and then copy the data back from MTP to TCP at the client side.  This causes a delay which may affect performance.  If TCP and MTP performance are close due to MTP/IP specific factors, this extra copying time may make HyperGate slower than ExpeDat or plain HTTP.

HyperGate Buffers

HyperGate must copy data from TCP to MTP at the server side, and then copy the data back from MTP to TCP at the client side.  If the network is very fast, or if the Web Browser is very slow, larger buffers may be needed.  If you are using HyperGate on a network faster than 100 megabits per second, you may need to increase its buffer size.  See the HyperGate documentation for details.

Browser Cache

Web browsers retain recently accessed data in local memory.  Future access to that data may then be drawn from this cache, rather than from the server.  The browser cache should handle both plain HTTP and HyperGate data.  When accessing cached data, the network will not be used and so performance cannot be compared.  When testing performance, use fresh data each time to eliminate caching effects.

Network Cache

Some network devices may keep a copy of previously accessed data.  This is similar to a browser cache, except that it may be shared among many network users.  Future attempts to access that data may then be drawn from this "cache", rather than from the server.  Some ISPs deploy "hidden" or "transparent" proxy servers which force you to use their cache, regardless of your system configuration.  Network caches may only benefit plain HTTP.  HyperGate transactions will not benefit from network caches unless it is specifically configured to use them.  When testing performance, use fresh data each time to eliminate caching effects.

Compression

Compression performed prior to the data leaving the web server will not affect the relative performance of HyperGate versus plain HTTP.  If you have a performance enhancement device that attempts to compress or reduce the data carried by HTTP, it must be deployed between hgserver and the webserver.  You may wish to disable such devices for testing purposes.

Dropped Connections

If either the web server or web browser experiences a problem, it may drop its connection to HyperGate.  If this happens, HyperGate will be forced to stop the transaction.  If you are experiencing dropped connections, investigate the web server and web browser to see if they are the cause.

Encryption

Encrypting and decrypting data requires several times more CPU processing on both the client and server.  If the CPU load is the limiting factor, turning off encryption may improve performance.  If you are using SSL compatibility, the webserver will also be performing its own encryption, in addition to MTP's encryption.  You may be able to improve performance without compromising security by using only MTP's encryption.  See the HyperGate documentation for details.

Performance Checklist

If MTP/IP appears to be performing poorly in a particular environment, perform the following checks to determine the cause.  You should read through the entire list before beginning, because some checks may be easier or faster than others to perform.  Most of these checks can be performed automatically by the MTP Test utility, which is available for download from the DEI support website at http://www.DataExpedition.com/support/.

Test

Download the MTP Test utility and run it at both ends of the network path in question.  It will perform a series of tests to analyze your network and report on its observed characteristics.  If possible, repeat the tests at different times of day and using throughput times up to 10 minutes.  The MTP Test utility can be downloaded from http://www.DataExpedition.com/support/.

Verify

Check your billing or service records to verify the intended capacity of the data lines at both the client and the server.  Remember that some links, such as DSL and cable, have different upload and download speeds.  Write down the speeds, link type, and IP addresses.  Compare this to the test results.  Beware of units errors: don't try to compare bits to bytes.  Use independent timing, such as a stopwatch, to measure performance.  Note what percentage of the link capacity is being used by each protocol.

Trace

Use the tracert or traceroute commands to measure latency and the number of hops between the client and servers.  If you cannot get through in BOTH directions between the client and server, but other traffic does get through, then you KNOW there is a firewall blocking traffic in between.

Firewalls

Make SURE that the tests are not being affected by firewalls, NAT, or VPN devices.  If possible, disable any software firewalls, NAT programs, VPNs, or other packet filters which may be running on the client or server.  CHECK the configuration of all routers, hubs, DHCP devices, NAT devices, VPNs, and modems to make sure their firewall features are disabled or configured to EXPLICITLY allow BOTH incoming and outgoing traffic and the ports used by your MTP/IP application.  The test utility uses port 8082 by default.

Tunneling

If a VPN is being used, check its documentation and configuration to verify that it DOES NOT tunnel UDP/IP over TCP/IP.  Devices which tunnel network traffic over TCP/IP, including "SSL VPNs" severely impair performance and are not compatible with MTP/IP.  Consider using an IPsec VPN instead.

Compression

Make SURE that none of the network devices is performing compression.  To test for network compression, build two test files each large enough to take at least 30 seconds to transfer.  One should consist entirely of zeros, the other should consist entirely of random data.  If the file consisting of zeros transfers much faster than the one consisting of random data, then something is compressing data in the network.  If you don't have an easy way to create zero and random data, using a plain text file and a compressed binary file will also work.

Network Service Provider

Check with your both your client AND server network providers to see if they are (a) blocking any ports, (b) using any kind of network compression technology, (c) using any kind of packet shaping, rate throttling, or bandwidth management technology.  If possible, have them disable these technologies, at least for the purposes of testing.

Hardware

Check that you are using modern networking hardware from reputable vendors.  Older or low-quality equipment may not conform to Internet Protocol standards.  If possible, try testing with different equipment such as CPUs, routers, and modems to see if a particular piece of hardware is causing the problem.

Contact DEI

Feel free to request technical support if you are unable to resolve any performance issues.  Be sure to let DEI's engineers know what steps you have already taken to isolate the problem.