Upload speed problem

[petrus]

Hi,
I'm having a serious upload speed problem.
I use FlashFXP 2.0 Build 906 on WinXP.
It worked well with ADSL before. But my ISP has been changed and I'm on VDSL now. They call TS(Time Sharing)-DSL. It's 20 Mbps(downstream+upstream) in theory but the best speed I saw was 233 KB/s.
Here is the test result by www.dslreports.com.
Down: 1813 Kbps, 1813 Kbps
Upload: 1846 Kbps, 1811 Kbps

The problem is the maximum upload speed by FlashFXP is just barely over 14 KB/s with VDSL. :mad: On the other hand, upload speed goes up to 233 KB/s while connected to eDonkey.
I tried CuteFTP Pro 3.0 and it uploaded at over 200 KB/s. So I switched to CuteFTP Pro 3.0 Trial for better upload speed. I don't like CuteFTP but I have no choice.:( How can I solve this problem? I need help. Please let me use my FlashFXP.

[MxxCon]

make sure your FlashFXP.exe is not modified or corrupted in any way.
to be sure redownload installation from www.flashfxp.com and nowhere else.

[petrus]

I'm a registered user, so I don't download it from anywhere except here. I just download it again. It's still same Build 906.
I know that upload speed varies depend on FTP servers. I'll show you another test results.
I connected to the same server at the same time(almost).

Upload speed( This server wasn't fast enough.)
1. CuteFTP Pro 3.0: 55.6 KB/s
2. WS_FTP Pro 7.6: 34 KB/s
3. SmartFTP 1.0.971: 25.5-32 KB/s (continuously up and down)?
4. FlashFXP 2.0.906: 14 KB/s

Also I just connected to http://www.pcpitstop.com and tested my connection.
Download: 1814 Kbps, 1814 Kbps
Upload: 316 Kbps, 316 Kbps

Doesn't it look something strange?
Compare it with the result from dslreports. It couldn't measure my upload speed correctly!!!
Is there any possibility that some programs don't know how to deal with VDSL?

[MxxCon]

what speed do you get from ftp.uu.net/tmp
it's anon uploadable and very fast
did you try any tcp/ip tweak from sites like dslreports or speedguide?

ftp clients don't care what type of connection you have. they communicate using TCP/IP protocol. winsock(tcp/ip) talk to your nic's drivers, which talk w/ nic, which talk w/ your dsl modem.
as you can see ftp clients are on a higher level and don't really need to deal with "vdsl, adsl, cable, dailup, etc"

[petrus]

I got download 223 KB/s and upload 23.6 KB/s from ftp.uu.net/tmp.
I havn't tried any TCP/IP tweak.

[MxxCon]

so everything is fine now?

[petrus]

No, still same problem.
My upload supposed to be same as download.
Also FlashFXP is slower than other FTP client.

[MxxCon]

what speeds do you get from ftp.uu.net/tmp using ffxp and using other ftp client.
also please try those tcp/ip tweaks from dslreports. it's possible that your connection is "optimized" for your previous adsl, but it's not optimal for vdsl.

[petrus]

Sure.
I checked out tweaking from dslreports.
It said
1. Enable TCP time stamping.
2. Choose RWIN between 5840 and 7300 (FAQ #586).
3. USA based? - Ping is high.
Minimum 204 ms
Maximum 213 ms

I set 1 and 2 as directed using Dr. TCP.(I got it from dslreports.)
USA based? - Of course NOT.

The test results after tweaking:

dslreports
Download: 220 kbps
Upload: 1306 kbps

ftp.uu.net/tmp
FlashFXP Download: 22.1 KBps
Upload: 23.6 KBps
CuteFTP Download: 21.4 KBps
Upload: 35.8 KBps

What a crap!
So I reset all settings to defaults.
The test results with default settings:

dslreports
Download: 1809 kbps
Upload: 1819 kbps

ftp.uu.net/tmp
FlashFXP Download: 225 KBps
Upload: 23.4 KBps
CuteFTP Download: 233 KBps
Upload: 36.2 KBps

As I understand, the tweak at dslreports is to fix a download problem. But that crap messed with my connection.
Any other suggestions?

[MxxCon]

sorry that tweak didn't work right for you.
it didn't work becuase it was based on what looked like very high latency connection.

[petrus]

I checked eDonkey again. It used my bandwidth in full.
1 download(15.1 KBps), 25 uploads(215.5 KBps)
My bandwidth is 233 KBps(download+upload). It's different from BellSouth ADSL which has download: 156 KBps and upload: 26 KBps. This VDSL is called a Time Sharing-DSL. There might be something to do with how FTP clients handle timing while uploading.
I hope that I don't have to wait for the solution until you have VDSL connections there.

[MxxCon]

well, from what i know VDSL is no differnt from ADSL or SDSL..
VDSL stands for "very high bit-rate DSL", which is same thing as adsl or sdsl only faster.

i don't know what is "time sharing-dsl" tho..

[petrus]

I found the manufacturer of my modem.
They call it TDSL(Time division duplex Digital Subscriber Line), my ISP called it TS-DSL though. Sorry about that.
You can get some information from here.
http://www.gigalink.co.kr/english/02pro/02pro_02tdsl.php
My modem is 'T-LAN SU-400'.
Hope you can find some clue.

[Voxxel]

I'm just going to throw out a few ideas here:

I could be mistaken, but I remember reading something about time-sharing internet where download/upload speeds would be throttled at certain times during the day.

Also, it may be that your ISP filters outgoing port 21 traffic to discourage people from running servers. The DSL Reports test transfers the test data via HTTP, not FTP, so it's probably using port 80 or 8080. Try uploading to an FTP that's running on a port other than 21.

Those are just a few ideas, take them with a grain of salt.

[petrus]

Thanks for your advice.
I'll try to test with FTPs with port other than 21.
I had a chance to upload files to my friend's FTP yesterday. The FTP server was Serv-U 4.0 with port 21. I used CuteFTP at first and I got 49.5 KB/s upload. I logged off and used FlashFXP. The upload speed dropped to 21.5 KB/s with FlashFXP. I switched back to CuteFTP. It gave me 49.5 KB/s upload again. So I had to use it until I finished uploading. How come is there so much upload speed difference between two? It's not ISP blocking some port problem.
Sorry about mentioning other products here, but I have no choice to explain the problem that others hardly believe. Also I want FlashFXP to remain as the best, otherwise I wouldn't post comparisons here.

[DYN_DaTa]

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

(j/k)

[petrus]

I don't think so.:)
But if it does so, why not? FlashFXP needs it too.:D

[petrus]

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]

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]

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]

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]

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.php?s=&threadid=1218

[bigstar]

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.php?s=&postid=12220

[darkone]

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.