Hi All,
Yeah, so I have dial-up. Stop laughing. :)
I would like some advice on making the best of my slow dial-up connection.
The behavour I observe when downloading files (http get and ftp both) is: a) Download holds steady for some seconds, say about 30 b) Rate stumbles, falling to zero for a few seconds c) Rate shoots up to 4 or five times nominal d) Rate declines back to nominal over a few seconds e) repeat from a)
A wireshark capture, if I am interpreting correctly, reveals that the window ( this is the TCP congestion window cgwnd?) increases during (a), whereupon at (b) a segment or two gets dropped, dup ACKS and retransmissions ensue (some which seem to me to be unnecessary), the window is shortened, progress resumes as normal for awhile, then the whole cycle repeats.
So I imagine that packets from the high-speed sender are piling up somewhere in the path until eventually a buffer gets exceeded and a packet gets dropped.
Am I reading the situation correctly? Is there any way I encourage the other end of the link to throttle back?
Thanks for any comments and education. And really, stop laughing!
-Shawn
Do you have call waiting on your phone line?? There is a code to send when you initiate your data call. I think it is *70 to disable call waiting when you start the call to your ISP.
You may also want to look into changing your MTU settings. I recall that I had to change this with the OLD dial modems to optimize the packet size. This could be causing the buffer overflow, start and restart of the session.
Really those two items are what immediately comes to mind.
Brian Kelsay
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Shawn C. Powell Sent: Saturday, June 25, 2011 10:09 AM To: [email protected] Subject: TCP experts - improving dial-up performance?
Hi All,
Yeah, so I have dial-up. Stop laughing. :)
I would like some advice on making the best of my slow dial-up connection.
The behavour I observe when downloading files (http get and ftp both) is: a) Download holds steady for some seconds, say about 30 b) Rate stumbles, falling to zero for a few seconds c) Rate shoots up to 4 or five times nominal d) Rate declines back to nominal over a few seconds e) repeat from a)
A wireshark capture, if I am interpreting correctly, reveals that the window ( this is the TCP congestion window cgwnd?) increases during (a), whereupon at (b) a segment or two gets dropped, dup ACKS and retransmissions ensue (some which seem to me to be unnecessary), the window is shortened, progress resumes as normal for awhile, then the whole cycle repeats.
So I imagine that packets from the high-speed sender are piling up somewhere in the path until eventually a buffer gets exceeded and a packet gets dropped.
Am I reading the situation correctly? Is there any way I encourage the other end of the link to throttle back?
Thanks for any comments and education. And really, stop laughing!
-Shawn
Am I reading the situation correctly? Is there any way I encourage the other end of the link to throttle back?
Good FTP software, like the kind that is stock in Tru64, does rate-limiting. But not all ftp software does. If you've got a Linode (or equivalent) you could transfer to there, then transfer home, with control over the remote end. Also if your ISP has a cache, you could use it for rate smoothing, as the negotiation cycle will go quicker against a nearer remote endpoint.
Hi Guys,
Thanks for your ideas.
I did try disabling window scaling (net.ipv4.tcp_window_scaling=0), forceably limiting the window to max 64K. This did reduce the frequency of dropouts which seems to confirm my theory. Those that remain are probably actually due to line noise. Of course, the setting affects all network interfaces.
I do not have call waiting. I tried reducing the MTU below 1500 once before. It seemed to generally make things worse. Packet fragmentation problems perhaps?
I will look into some better ftp sofware.
Thanks again!
-Shawn
On Wed, Jun 29, 2011 at 10:22 PM, Shawn C. Powell [email protected] wrote:
I will look into some better ftp software.
On the server end, not the client, is what I was talking about. A proxy with a rate-limited connection it what you need --- without setting such a thing up specifically, you could try setting up TOR for instance to slow things down, just to try something; also, what happens if you use torrent instead of FTP?
On Saturday 25 June 2011 10:09:28 am Shawn C. Powell wrote:
Yeah, so I have dial-up. Stop laughing. :)
I would like some advice on making the best of my slow dial-up connection.
For file transfers, you might be able to use kermit or zmodem. They have packet retransmission capabilities designed to work over links with losses and lag. iirc Kermit was designed to be used over satellite links where lag was the bigger problem and zmodem was developed to cope with dropped packets.
Getting the remote system to speak one of those protocols will be the challenge.
On Tue, Jul 5, 2011 at 4:38 PM, Jonathan Hutchins [email protected]wrote:
On Saturday 25 June 2011 10:09:28 am Shawn C. Powell wrote:
Yeah, so I have dial-up. Stop laughing. :)
I would like some advice on making the best of my slow dial-up
connection.
For file transfers, you might be able to use kermit or zmodem. They have packet retransmission capabilities designed to work over links with losses and lag. iirc Kermit was designed to be used over satellite links where lag was the bigger problem and zmodem was developed to cope with dropped packets.
Getting the remote system to speak one of those protocols will be the challenge.
There's xmodem s/w for unix out there in the wild with my name on it.
-
Andrew Beals -
David Nicol -
Jonathan Hutchins -
Kelsay, Brian - Kansas City, MO -
Shawn C. Powell