Upload speed problem - Page 2

DYN_DaTa · 01-21-2003, 08:19 AM

Humm... maybe spyware/adware inside CuteFTP is boosting your upload speed... who know

(j/k)

petrus · 01-21-2003, 09:49 AM

I don't think so.

But if it does so, why not? FlashFXP needs it too.

petrus · 01-23-2003, 09:20 PM

I had a chance to test FlashFXP with another FTP yesterday.
The FTP was running Serv-U 4.0 with port 21.
The upload speed went up to 27 KBps with FlashFXP. I was quite happy with the result at first because it's the highest upload speed with FlashFXP. So I switched to CuteFTP for testing. What a surprise! The upload speed went up to 113 KBps immediately with a single file transfer. I added more files to queue and upload speed went up to 167 KBps with 2 files transfer at once. Probably the FTP was on ADSL. As you can see from the result, my ISP doesn't filter port 21.
Do I need anymore proof?
FlashFXP needs to be code optimized. Currently it's the slowest FTP client among popular ones. Current build of FlashFXP is unusable because of slow speed.
I'm waiting for a new and improved version.
Please...

bigstar · 01-23-2003, 11:24 PM

Not all network environments are the same. That being said when using FlashFXP on a 100mbit lan I have no problem maxing out the bandwidth both when uploading and downloading.

I'm sorry you're not getting optimal transfer speeds on your system but there isn't much that can be done. There are a number of different ways to send/receive data ising TCP/IP, some may be suited better than others depending on the network environment. FlashFXP was designed using one method if there is a better method of sending/receiving data to change to such a method would require major code changes. This is very unlikely, unless we decide to rewrite FlashFXP.

DYN_DaTa · 01-24-2003, 08:48 AM

Quote:

Originally posted by petrus
Current build of FlashFXP is unusable because of slow speed.
I'm waiting for a new and improved version.
Please...

Unusable?Â¿... LOL ... Currently FlashFXP is one of the best Windows FTP clients: without spyware/adware components, with a nice and clear GUI, a priority queue list, minimal CPU usage, without critical security flaws, custom commands for many Windows FTP servers, it has one of the BEST technical support team, etc...

If you don't like this program code your own FTP client, but please, don't use the word 'unusable' :P

darkone · 01-24-2003, 09:45 AM

Best settings for windows are the defaults (imo). Bigstar, could you add option to disable nagle algorithm (or maybe you've disabled it already) - that could help performance in certain circumstances. Also options to set socket (send/recieve) & internal transfer buffer sizes could help people to get optimal performance on their system.

bigstar · 01-24-2003, 02:20 PM

In the past we offered settings to disable the nagle algorithm and adjust the send buffer, adjusting the recv buffer isn't nessary as by default it's quite large.

Most people adjusted these options without realizing the effect and then complained when the performance suffered. I don't recall anyone benifiting from these options. The options were removed.

There is one other option you can try which is to enable high thread priority.
http://forum.flashfxp.com/showthread...&threadid=1218

bigstar · 03-05-2003, 02:11 AM

I've posted a new public beta (build 909) for registered users, This build offers an option to adjust the upload packet size.

XBOX users have reported an increase in performance when changing the packet size to 2048.

I would recommend adjusting the packet size and see what size works best for your internet connection. Try 2048 first.

For details regarding build 909 please visit this thread
http://forum.flashfxp.com/showthread...=&postid=12220

darkone · 03-05-2003, 03:24 PM

I've noticed the same issue in winsock. Sending buffer larger than X to system Y with one send() call may cause noticable performance decrease (where system Y is running operating system made by microsoft.. some of my users have suggested that send size should be limited to RWIN size - tcp header size... but again, you can have no idea what receivers RWIN is, if he has 'tweaked' it.. [god bless those lamers who are ruining application compatability with their tweaks, and then blaming developers])

The TCP Receive Window size is the amount of receive data (in bytes) that can be buffered at one time on a connection. The sending host can send only that amount of data before waiting for an acknowledgment and window update from the receiving host. Matching the receive window to even increments of the MSS increases the percentage of full-sized TCP segments utilized during bulk data transmission. MSS is the MaxMTU - 40 bytes for TCP and IP headers.

My assumption is that when sending from winsock to winsock, send() is trying to pass too large chunk of data in one window. So when you're sending 64kb and RWIN size on receiver is 8KB, 56kbytes will be rejected. On 100mbit network this means that your max speed will be capped to 8/64*100mbits = 12,5mbits = 1560kb/s. However TCP also reduces send speed temporarily when it receives error => your speeds will be much less than 1560kb/s.

Possible solutions: dump the windows, sue microsoft, kill tweakers, kill yourself, set your rwin to 64kbytes.