Auto Restart slow connections

Hi. In some other downloading software I've used over the years, there is often an option where if the download speed falls below a specific threshold for a length of time, the download will be terminated and retarted with resume, assuming resume is supported by the server.

I'm having this problem currently while downloading files from my remote server. The downloads start off fast at around 350KB/s, but over the course of 10 minutes or so, drop to less than 10KB/s. I can simply click the Stop and Start buttons in the queue and it's back up to full speed again.

These are large downloads which will take a couple of hours at full speed, but a day or more at the usual crawal speed. During the day I'll Stop and Start the queue when I remember to do so, but I can't do that overnight.

I hope you can consider an option in SmartFTP. It shouldn't be difficult to implement.

Ross.

Is this a common situation? I cannot only think of 2 situations:

1. Traffic shaping setup time
Traffic shaping may need some time to become active but it's usually setup after a relative short time (30 seconds). So what I have seen is the following:

First 30 second: full speed (not limited)
After the 30 seconds: traffic shaping active. reduced speed.

Maybe some kind of traffic shaping algorithm takes minutes to become active?

2. TCP window size (send/receive buffer size) is reduced but never increased
Did you do some testing with an operating system with a modern TCP/IP stack (e.g. Windows 2008/Vista or higher)? Because it dynamically adjusts the receive buffer size.

Regards,
Mat


Is this a common situation? I cannot only think of 2 situations:

1. Traffic shaping setup time
Traffic shaping may need some time to become active but it's usually setup after a relative short time (30 seconds). So what I have seen is the following:

First 30 second: full speed (not limited)
After the 30 seconds: traffic shaping active. reduced speed.

Maybe some kind of traffic shaping algorithm takes minutes to become active?

2. TCP window size (send/receive buffer size) is reduced but never increased
Did you do some testing with an operating system with a modern TCP/IP stack (e.g. Windows 2008/Vista or higher)? Because it dynamically adjusts the receive buffer size.

Regards,
Mat

I have the same issue. I will try Option 2 for this.