The maximum speed of TCP/IP transfers through a SLIP or PPP connection is limited by the speed of the modem. A 28.8 Kbps modem can never keep up with a 1544 Kbps (or faster) internet path. (Although, if your retail access provider buys his wholesale access at 56 Kbps, you might never get the chance to try.) With an uncompressible (already compressed) file, you should be able to get 3.2 KBytes/sec transfers over a 28.8Kbps connection; 2.7 KBytes/sec over a 24 Kbps connection; 1.6 KBytes/sec over a 14.4 Kbps connection; etc.
Note: A good approximation is that each Byte/sec of delivered TCP data rate requires 9 bps of modem connect rate with V.42 error correction, and 1.25 times that number of bps in com port unloading rate. Downloading compressible files should give correspondingly greater effective transfer rates with the 2-to-4 times multiplicative effect of V.42bis data compression. (This has nothing to do with Van Jacobson header compression - the disabling of which could reduce that 3.2 KBytes/sec to 3.1 or even 3.0 KBytes/sec, depending on packet size.)
If you observe such transfer rates at some points in a download, but the overall average is less, that average had to have been reduced by pauses between TCP/IP packet transfers.
If the pauses were just due to the fact that the server was too busy to send as fast as you could receive, turning-on TCP Trace (if you're a Trumpet WinSock user) would show a smooth sequence of MSS-sized segment transfers, but with pauses. In that case, if you turned-on Trumpet TCPMeter, you'd be able to open a second window to another server and see yourself using the difference between the average file download rate and 3.2 KBytes/sec for a simultaneous download from that second server.
If the problem was IP routing congestion on the then-available Internet paths between you and the server, RTOmax time-outs by the server (waiting for your ACKs) would cause him to re-transmit, resulting in unacceptable segments and pauses for TCP re-synchronization. (Out-of-order segments that took different routing paths through the Internet could cause similar pauses.)
There's not much you can do about a busy Internet. However, if the pauses occured because your machine failed to ACK damaged packets, you might be experiencing PPP frame check errors, which would also result in pauses for re-transmission.
These could be due to com overrun errors caused by your machine not servicing com port interrupts fast enough to keep up with the rate you promised the modem in your com port setting. They could also be due to inadvertently disabling your V.42 error correction, which you might not notice on a very clean phone line. (On a line with any amount of noise, you'd find that the error rate would swamp TCP/IP and that PPP would probably hang-up your connection.) These are problems in your data link layer, and can be eliminated.
Similarly, if your machine and the server agreed on a TCP MSS that was not less than the smallest IP MTU of all the routers on the Internet path between them (minus 40 bytes for headers), you'd experience slowdown from IP packet fragmentation. If your TCP RWIN was set to more than the size of the number of TCP data segments that would fit in the number of IP packet buffers your Internet service provider allocates per dial-in port, the resulting dropped segments would also cause re-transmission pauses. These are problems in your TCP/IP layers, that can also be eliminated.
The balance of this tutorial FAQ is intended to give you the knowledge needed to understand what your WinSock settings are (in words - not just acronyms) and what roles they play, and to help you eliminate those speed-wasting factors that you can control.
This FAQ is available as a Windows Help® file for off-line viewing
Copyright© 1995 by Albert P. Belle Isle