FlashFXP chokes upstream

I'm using FlashFXP 3.6 and BulletProof FTP Server 2.1.5 in Windows 2000, on a cable connection with a lowly 200 kbit upstream and 2 Mbit downstream. If someone downloads a file from my FTP server, they get the full 200 kbit speed and I don't even notice that anyone's there (unless I notice that the tray icon has changed colour). If I upload a file myself in FlashFXP to any server, it grinds my connection into the ground. I have to limit the speed to 16 kB or less to even be able to use the Web, but now I'm uploading slowly.

I tried removing the speed cap and bringing the buffer size down to 4 kB, but that doesn't help much. I don't know what FlashFXP is doing, but it seems to really hammer packets out with excessive brute force.

FlashFXP will attempt to send a file as fast as possible. There are many factors as to how fast the transfer will go. Your upstream is more critical of a bottleneck than your downstream because the pipe is much smaller and using 100% of the pipe causes high latency which in turn effects your overall web browsing experience.

Your option is as you've already stated to enable a transfer speed limit, the only way to balance things out is to lower your transfer speed.

If your router supports QoS you can configure different policies to give specific traffic different priorities, giving FTP traffic the lowest priority and say everything else high priority. Normally these policies are defined by IP or PORT ranges.

My point was, BulletProof FTP Server manages to sustain the SAME transfer rate as FlashFXP WITHOUT overloading my upstream. I know it's possible, therefore, to achieve high throughput without straining the connection, but I don't know quite what the difference is. It's possible that on a much higher upstream, BPFTP wouldn't be reaching maximum speed any more, but I can't tell.

I also don't recall IM file transfer causing any bother either -- FlashFXP is by far the worst program I have for choking my connection. It seems to be really hammering away at the expense of everything else.

Sadly, I don't know what I'm looking for to be able to monitor and measure how different applications compare, and see what trade-offs would arise from each program's approach.

The relationship between the client and server software is a huge factor when understanding TCP/IP performance.

Things that we'd need to is stuff like are the people using your ftp server using FlashFXP, or when you test uploading with FlashFXP are any of the servers BulletProof FTP?

We also need to make sure we're testing with identical settings on both ends too.

On my local LAN I often do performance profiling and by changing things like packet sizes you can get huge ranges of results. While you changed FlashFXP to use 4kb that may of had little impact due to the configuration server side.

If you find something that might make a difference I will look into it.

FlashFXP is playing silly buggers. It's been using the All Users config since around November 2007 -- I had to get Filemon on its case to figure out why settings were not being saved to the ini file in my personal Application Data\FlashFXP folder ...

I've discovered how to read off send packet size -- TDIMon. BulletProof FTP is using 4096-byte packets, although they're all being fragmented to 1200-1400 later (indicated in WireShark).

I tried setting FlashFXP.ini directly, to SPS=1, and that seemed to cure it (TDIMon shows it sending 1024-byte packets), but now the cure has evaporated, so it's one of these things that's very hard to actually pin down. It does seem though that buffer size is nothing to do with it, since 8 kB and 4 kB behaved the same.

Given that FlashFXP and BulletProof FTP use the same packet size, and achieve the same speed, I don't see how one of them can be choking the upstream when the other does not? I don't have an intimate knowledge of TCP/IP and especially not under Windows, so I don't know what other variables exist. The problem is that I have no formal method to measure performance -- there's no readout that tells me what effect FlashFXP has, and in all performance cases such as these, your mind plays tricks on you and you end up totally exasperated and wondering if you just imagined the whole lot. I've just tried putting FlashFXP on idle CPU priority, but again, no change, not even with 1024 kB packets that it's still set to.

(Oh should have said, but I erased it when I thought for a while that 1024-byte packets fixed it -- it doesn't matter what site I'm uploading to, or who's downloading from my server with what client. The results are always the same. At least, not that I've ever been aware of anything otherwise. But since all outbound packets are being fragmented to between 1200-1500 bytes, it probably cannot...)