Contact Site map Home

Technical Support
(Historical information only. We hope you find it to be a beneficial resource)

Diagnosing Slow Connections

All communication across a network is broken into packets before sending and is reassembled at the receiving end.

Let's say we are sending a 100 page letter to someone and his mailslot is only big enough for one page at a time. So we have to send each page in its own envelope with its own addressing and stamp. Several things can happen:

  1. All the envelopes are delivered without mishap (giggle).

  2. None of the envelopes are delivered (either you or the receiver
    or both are not online or your ISP has router difficulty or Atlanta
    has been hit in a pre-emptive tactical nuclear strike).

  3. Some of the envelopes are delivered.

If it is the last case, and it usually is, success depends on how many of the envelopes are delivered. Some protocols will try to resend lost envelopes but in the end, there will usually be some missing information. If you try to read a book with a few missing pages, you still  get the gist of the story as long as the missing pages are not consecutive and don't include critical plot changes. In the same way, the web server, ftp server or your local computer can recover from some missing packets to finish your upload or download.

If say, 95% of the packets arrive intact, the receiving computer can assume the missing material from context.

For example:

She _ells seashe_l_ by the _eashor_.

Is easily translated into:

She sells seashells by the seashore.

If say, only 80% of the packets arrive safely, there is not enough to put the whole message back together, this:

_he ___ls __ashe___ b_ the __asho__

is not enough to work with.

If the receiver sees that it has received less than 80% of say, the first 20% of the message:

__e se___ s_a___

it gives up early and sends a message like "blocking call canceled" or "connection failed".

Web browsers will give slightly different error messages.

Missing or delayed packets will be the cause of 90% percent of your connection difficulty.

The first step in diagnosing connection problems is to run a traceroute. This will help to determine what path your connection takes across the Internet to reach our servers. The traceroute tool is not intended to gauge your Internet connection as a whole but to show the specific path you take to a specific location. If you have a Windows95 or WindowsNT computer, you can use the built-in traceroute program to do this.
Macintosh users can get a free traceroute utility from allmacintosh.com

Click on the 'start' button and go to 'programs'. Choose 'MS-DOS prompt'
('Command Prompt' in NT) and at the 'c:\windows>' prompt, type:

    tracert yourdomainname.com

You will be presented with a string of numbers representing the connect times of three packets sent to the next server in line through which you must pass on your way to our server.  That server then sends three packets to the next server in line and reports those times back to you. If you see an asterisk in place of a connect time, this means that packet was placed on a network wire at the same time another server placed a packet on the wire and they overwrote each other (commonly called a data collision). This is indicative of heavy traffic on that network and three asterisks on the same line mean that may be a dead connection. In this case we suggest logging off and logging back on to your ISP to see if you can get a different connect route. If you see long connect times (consistently in excess of 400ms), the server on that "hop" may be busy servicing other packets . This traceroute is only a snapshot of network traffic at that moment in time. It should be run several times to determine the "trends" of the traffic. To save it to a file for future reference, type:

tracert yourdomainname.com > C:\trace.txt

This will create a file in the root directory of your hard drive named 'trace.txt' that you can then view with 'notepad'. Any subsequent traces can be appended to the trace.txt file with:

    tracert yourdomainname.com >> C:\trace.txt

The next step is to determine the path that the server's packets take to you. You can connect to your site via the built-in Windows95 telnet program. Our telnet tutorial explains the steps (WindowsNT has the same Telnet program built-in).

Once you are at the telnet prompt on the server, type:

    traceroute 216.122.20.185

The number above should be the IP address of your current connection to the InterNet. If no number appears, our server was unable to determine your addresss and you will need to contact your ISP or network administrator.

The results of these server side traceroutes can be cut and pasted into a local file via notepad.exe or this command will send the results to you via email:

traceroute 216.122.20.185 | mail you@yourdomain.com

The symbol between the the IP address and "mail" above is known as "the pipe" and should be above the backslash on your keyboard.

If looking at the results of these traceroutes, both to and from the server does not yield any obvious answers regarding your connection, email them to us and we will investigate further. If the results point to specific traffic congestion somewhere between you and the sever, logging off your Internet connection and reconnecting may help. This may cause your ISP to assign you a different temporary local IP address which may take a different path to our server.

Shopping for ISP's should be done using the traceroute tool. Many ISP's offer free evaluation periods during which you may monitor the connection reliability with this tool. Remember to run the trace several times to get a feel for the "trend" of the traffic.

For a comprehensive modem connection trouble-shooting faq, click here.

 
 
[ Home ]   [ About ]   [ Plans ]   [ Designs ]   [ Graphics ]   [ Marketing ]   [ Hosting ]   [ Portfolio ]   [ Contact ]   [ Site Map ]
Copyright © 1995-2000 XyNexT Internet Strategies - All Rights Reserved Worldwide