Dear all,

Recently, I use lftp as a ftp client to upload some files to ftp server on wireless network(dial with WCDMA/GSM modem),
I find the upload rate graph is different from other ftp client ,such as filezilla.

When wireless network signal is not very good, lftp rate graph look like a jaggies zigzag line, while filezilla

rate graph look like smoothly.

After I catching uploading wireshark log, I find the reason as below:

1)After tcp connection is created, lftp send lots of tcp packets to wireless modem and wait response, but now, wireless modem need much time to transfer these packets to ftp server, so lftp wait a lot of time to send next serial packets.

when I look rate graph on PC, its look like a jaggies zigzag line.

2) But filezilla send packets according the the real network environment, that is , when network signal is bad, its send

less packets, so waiting time is not very long.

How can I solve this problem? thanks

lftp is a pretty simple client, and relies on the TCP subsystem in the TCP/IP stack to throttle the connection by adjusting the TCP window size and so on. The Linux kernel supports a number of different TCP congestion control algorithms, at perhaps the one used by your kernel isn't very well-suited for this particular scenario.

I don't know anything about FileZilla, but it may very well be "holding back" packets and do its own congestion control by, say, using a smaller TCP window size. That would explain why the transfer appears to go smoother. I wouldn't expect this to dramatically affect transfer times, but it would make the connection appear much less congested as the buffer in the modem isn't filled to capacity.

You could try switching to another TCP algorithm, if your kernel supports it. If you have a file called /proc/config.gz on your system, the command should produce a list of supported TCP congestion algorithms, and whether they're compiled as modules or directly into the kernel. You switch algorithms by echoing the name of the desired algorithm (for instance, "Vegas") to the /proc/sys/net/ipv4/tcp_congestion_control file. See this article for more details.

The real problem here is actually the buffer in the modem, which from what you're saying is way too large. Congested connections should be dropping packets, not putting them in a huge queue.

Thanks for your reply.

But I use lftp on windows with Cygwin platform, so I can not set TCP algorithm following your methods.

From your explanation, I guess if the lftp's upload algorithm is not suitable for Windows, but suitable for Linux ?

If that is true, I need to try other ftp clients.

Like most TCP applications, lftp doesn't use a specific algorithm. It just feeds data to a TCP connection, and leaves it to the IP stack of the operating system to adjust window sizes and throttle transfer speed.

Since the host OS is in fact Windows, there is (AFAIK) little you can do to change the behaviour of the TCP subsystem in the IP stack. A different and more advanced client that overrides the local IP stack and performs its own queuing and throttling would be one solution.

Another approach would be to install an application that can queue, prioritize and throttle all IP traffic from a Windows host, such as NetLimiter. Yet another would be to get a decent modem.

I try a lot of lftp settings, but it doesn't work, such as "set sftp:max-packets-in-flight 16"

If I use "set net:limit-rate" to limit the max rate to suit the modem real rate, such as 100Kbps, the upload rate graph become smoother.

But limit rate is not a better method, because of wireless rate is dynamic.

So...