New FTP PPC client speed benchmarks &WM5 compliance&Wizard EDGE thruput speed report

[Menneisyys]

Just published at http://www.pocketpcmag.com/blogs/index.php?blog=3&p=508&more=1 - feel free to read if you want to know everything you need to know about current FTP clients, their WM5 compliance etc.

[thefunkunfaked]

Theoretically, FTP transmission can only be efficiently optimized on the networking devices or over the infrastructure that is being used through traffic engineering, not on the client side. If done this way, it would not make much of a difference which client you used.

The user does not have much control over the GPRS EDGE network prioritization and traffic flows.. However with a good understanding of the nature of 802.11, TCP and FTP streams in particular, you can make the most of your 802.11/TCP/FTP data transmission. :D

[Menneisyys]

Theoretically, FTP transmission can only be efficiently optimized on the networking devices or over the infrastructure that is being used through traffic engineering, not on the client side. If done this way, it would not make much of a difference which client you used.


Theoretically, yes. But practially, internal bottlenecks (unoptimized code) in some FTP clients really slow down downloading. For example, the FTP module of Resco Explorer really s*cks (it's five times slower if you download to a storage card than in this respect decent FTP clients) at high-speed transmission. This is why it's really worth considering which FTP client to use, particularly if you download a lot via FTP. (The same stands for HTTP downloads - see my other benchmark.)

[thefunkunfaked]

Theoretically, FTP transmission can only be efficiently optimized on the networking devices or over the infrastructure that is being used through traffic engineering, not on the client side. If done this way, it would not make much of a difference which client you used.


Theoretically, yes. But practially, internal bottlenecks (unoptimized code) in some FTP clients really slow down downloading. For example, the FTP module of Resco Explorer really s*cks (it's five times slower if you download to a storage card than in this respect decent FTP clients) at high-speed transmission. This is why it's really worth considering which FTP client to use, particularly if you download a lot via FTP. (The same stands for HTTP downloads - see my other benchmark.)

All that would be required is to understand the nature of the streams with each individual application and set a specific threshold for all applications using that service (FTP or HTTP) and optimize it through the network.

In a perfect world, the developers would have a complete understanding of the difference in nature between streams over different infrastructures, subsequently allowing you to choose the type of network/media your stream is traversing (802.11b, 802.11g, GPRS EDGE, 3G UMTS, USB -- Main Memory, SDIO). Since they don't, only you can make it more efficient, so long as it is an infrastructure that you have administrative control over.

[Menneisyys]

All that would be required is to understand the nature of the streams with each individual application and set a specific threshold for all applications using that service (FTP or HTTP) and optimize it through the network.

Well, you can surely throttle the bandwidth but that won't help the inefficiency/unoptimization problems mostly with the Resco FTP client (or, as far as HTTP downloaders are concerned, the current version of Opera and Vito Downloader). That is, if you use Resco for downloading to a storage card over a fast connection, the performance will most definitely suffer and the download time will always be much higher than with other clients.

[thefunkunfaked]

All that would be required is to understand the nature of the streams with each individual application and set a specific threshold for all applications using that service (FTP or HTTP) and optimize it through the network.

Well, you can surely throttle the bandwidth but that won't help the inefficiency/unoptimization problems mostly with the Resco FTP client (or, as far as HTTP downloaders are concerned, the current version of Opera and Vito Downloader). That is, if you use Resco for downloading to a storage card over a fast connection, the performance will most definitely suffer and the download time will always be much higher than with other clients.

Why would you want to throttle the bandwidth? That will not help you and it could potentially make your data stream worse.

Your baseline analysis showed that while specific client software was more efficient in handling traffic under certain circumstances, other software was not. Deductively, the nature of the flows between one and the other differ. More specifically, the TCP windowing method is most likely inefficient under some circumstances, but efficient under others.

Your assumprion to "throttle the bandwidth" makes no sense, since the nature of TCP is to throttle itself due to the effects under certain circumstances through windowing mechanisms.

TCP windowing mechanisms and are immediately in the hands of networking devices and only intermediately in the hands of a host, let alone client software. These are fundamentals to networking. Your article or blog referenced the speed of data streams.

[Menneisyys]

More specifically, the TCP windowing method is most likely inefficient under some circumstances, but efficient under others.

Now I understand. I don't think fine-tuning networking parameters would help in this case. I don't think the Resco client would be capable of substantially better throughput with "tweaked" parameters. It's probably like the built-in File explorer vs other, alternative file handler tools on the Pocket PC: File Explorer is about 3 times slower at writing to storage cards than Resco File Explorer or Total Commander. The Resco FTP client may be using similar libraries (unlike, say, vxFtp) as the built-in File Explorer; maybe this is the reason for it being so slow.