• Please review our updated Terms and Rules here

Features for an FTP client

I don't even care if you are running at 4.77Mhz - I'd just like some speed comparisons on any machines. I'm measuring with a 386-40 and I want to see what other people are getting on their machines kind of as a sanity check.

Mike
 
Speed comparisons

Speed comparisons

Software:
WattFTP version .70 (FTP70)
WattFTP version .65 (FTP65)
LXFTP version 2.5 (LXFTP)

Client OS: MS-DOS 6.22a
Server OS: Linux 2.6.15-53-386

Hardware:
Client: P133 running FTP from ramdisk
and Intel LAN595 10 Mbit/s 16bit NIC
Server: proftpd on 2.8 GHz w/ 10/100 on LAN

Transfer files:
WORDS TXT 3,141,823
BINARY ZIP 3,287,331
SMALL TXT 4,097


Code: 
Results using the 3Mb ascii and binary files:

          TXT put   TXT get      BIN put    BIN get
LXFTP
 - best     7.1       5.7          7.2        5.8
 - ave.     7.4       6.0          7.3        5.8

FTP65
 - best    11.2       6.0         11.1       20.9
 - ave.    12.6       6.1         14.9       21.0

FTP70
 - best  (note 2)     6.1       (note 2)     21.0
 - ave.               6.2                    21.3

NOTES:

1. The 3Mb files were tried 3 times and the best of 3 is shown
along with the average. Numbers are in seconds and rounded
up to nearest tenth.

2. FTP70 has problems uploading. I stopped both the binary
and ascii uploads after 100 seconds at which point the file
was approximately 7% done. Ctrl-C and Ctrl-break does not
work. A complete reboot is needed. In one case it lost
keyboard control too, requireing a power off.

3. Both FTP65 and FTP70 are slow get BIN files. The time
to 100% above was around 7 seconds. The remainder (14s)
was waiting for the prompt to return.

4. FTP70 can upload small ASCII files quickly. I tested with
the 4k text file and the best put was 1.8 seconds and with
a similar average.
 
Ole Juul,

That is some great information ... So if I compare to my numbers from earlier, I'm getting about the same performance from a machine that has 1/3rd the clock speed. That makes me warm and fuzzy inside. ;-0

One thing I don't understand is the ASCII mode transfer numbers. On a DOS machine, the end of line indicator is CR/LF which is the same as it is for the ASCII mode that FTP clients and servers are supposed to use. So basically a DOS machine doesn't have to do anything if it wants to use ASCII mode because it already uses the right line terminator. All of the work would be on the other side, where CR/LF has to be translated in to the appropriate end of line indicator. (ie: Unix only uses LF, so it has to do the work to translate to CR/LF and vice versa.) All it has to do is tell the other side that it is an ASCII or a BINARY transfer - the actual transfer times should be exactly the same.

On an unrelated note, I have been plagued by a bug the last two days, but I finally found it. When I was doing an 'ls' the other side was opening the data connection and sending the data so fast that it was completing before the control connection was getting the message to start receiving data. My code caught the bits and did *almost* everything right, but it never occured to me that the transfer would be started and done so quickly so I missed the opening of the connection and the closing of it. It's all good now.

I expect to have a usable beta version in a week or so.
 
mbbrutman: I'm getting about the same performance from a machine that has 1/3rd the clock speed. That makes me warm and fuzzy inside. ;-0
Click to expand...
Well done! You've got good reason to be proud.

Regarding ASCII transfers. Of course anything that indicates a possible bug or bad code is interesting, however, text files typically aren't 3Mb and would be zipped to a much smaller size if they were, and so would transfer much faster anyway.
mbbrutman: I expect to have a usable beta version in a week or so.
Click to expand...
I'm looking forward to it!
 
ok, here is a speed test on my supersport 8088 running @ 8 MHz in turbo mode..

i didn't have enough free space for the 3.2 MB test, but anyway i just wrote a 5 line QB program to make a 900 KB file full of nulls.

FTP v0.65 results:

GET = 921,600 bytes in 53.67 seconds ( 16.73 KB/s )
PUT = 921,600 bytes in 43.67 seconds ( 20.57 KB/s )

it might be important to note that being a "laptop" (i use the term loosely) i had to use my xircom parallel adapter. probably affects the speed fairly significantly. on the other hand, i know the xircom can perform much faster than this for example on my 486 notejet. i got steady downloads at 75 KB/s and that was just in nibble mode, so the xircom shouldn't be any kind of bottleneck for this old machine.

i'd test it in another 8088 with an ISA NIC, but like i said before the SS is my only 8088 with a working hard drive. :(

mike, i'd love to test your client on that computer and see what i get.
 
Mike Chambers:
FTP v0.65 results:

GET = 921,600 bytes in 53.67 seconds ( 16.73 KB/s )
PUT = 921,600 bytes in 43.67 seconds ( 20.57 KB/s )
Click to expand...
I don't understand how you are getting faster puts than gets when my results are so strongly biased the other way. That was an ASCII file right? Also, I counted from "enter" to "return to prompt". Do you also get delays from transfer completion to "return to prompt"?

BTW: Try the LXFTP, it looks the same, it's got way more features, uses the same config and can be renamed for a straight drop in, etc. You'll like it.
 
Ole Juul said:
I don't understand how you are getting faster puts than gets when my results are so strongly biased the other way. That was an ASCII file right? Also, I counted from "enter" to "return to prompt". Do you also get delays from transfer completion to "return to prompt"?

BTW: Try the LXFTP, it looks the same, it's got way more features, uses the same config and can be renamed for a straight drop in, etc. You'll like it.
Click to expand...

it might be because the parallel port is unidirectional, so data coming in has to be read using the "nibble" technique. and no i used binary mode. there is maybe a 1-2 second delay after the transfer completes.

i will try LXFTP too, it sounds good.
 
I thought I would compare the times of text
file transfer using binary mode. These times are
using the same setup as my previous post and with
LXFTP. The 3Mb "words.txt" file was transfered
using BINARY mode.

Perhaps I should have mentioned it in my earlier
post, but these times are derived using a stop
watch. The times are recorded to 1/100 sec and
averaged, then rounded to 1/10 sec. The reason for
using a stop watch is that the computer reported
times were wildly incorrect and of dubious value
in the real world. They probably could be used for
comparison in a few circumstances, but not all.

Here then are both the real world (stopwatch) and
the computer times for put and get. This is an
average of 3 samples of a 3Mb ASCII file using
BINARY mode with LXFTP.


Code: 
         Real     Computer
PUT      7.1         3.2
GET      5.5         3.7

I should have mentioned (for easy comparison) that the realtime
put and get times posted earlier using ASCII for the text file were

PUT 7.4
GET 6.0

At least in this case, BINARY speed is about the same as ASCII
when transferring a text file.
 
Last edited:
Terry Yager said:
Does this mean you got the ol' SS fixed? (Or are you using an external monitor)?

Sorry for the OT inquiry...

--T
Click to expand...

i'm just using an external for now... i'm still thinking about your offer, but i hate to send parts around. nothing against you and i'm sure you can fix it, i just want to keep it together. besides i was looking at it again, and i think i may just be able to fix it. i was going to try splicing some small wires right into the wires coming out of the monitor and soldering it right to the connection point of the pins on the board. it's a bit ghetto, but if worse comes to worse i can get a part somewhere probably. it should be easy to do.

this laptop has seen better days. ;)
 
First Version!

First Version!

Here - try this ...

http://www.brutman.com/Dos_Networking/ftp-0119.exe

For the DHCP client or directions for static setup check out the normal mTCP pages at:

http://www.brutman.com/Dos_Networking/mTCP.html


Here is what I implemented:

  • Built in DNS resolver
  • PASSIVE and non-passive modes
  • BINARY and ASCII modes
  • Shell to DOS for quick commands
  • Built in DNS resolver
  • Scriptable - send commands in through STDIN
  • Progress indicator during file transfers (will be improved)

And here is what I need to work on:

  • Mget and put
  • A command history buffer
  • Whatever else you guys/gals point out that I forgot


I'm interested in your early feedback, performance reports, and comparisons to other FTP clients.

Mike
 
Again I used a stop watch because the computer
reported values were wildly off. The program
ran in a ramdisk so there was no read/write wait.
Three tries were recorded to 1/100s and the results
averaged to 1/10s. For reference, the program
reported time is reported as "Comp".

The same two files were used (3Mb Ascii and 3Mb
binary) so the numbers can be compared to my
earlier report.

Code: 
            Real   Comp

ASCII put   6.7     4.8
ASCII get   4.8     3.6

BIN   put   6.7     4.9
BIN   get   5.0     3.1

W00t!
You've done it!
I'm sure there will be some bugs, but that was an easy
setup, and a successful run. Very incouraging. :)
 
Hmm .. I don't know why the times are so far off on your machine. I just checked the 386-40 with a stop watch and found the reported times to be accurate.

Time is measured in the program starting after the file open but before any data is sent or received. If you are on a very old machine (8088 class) with a larger hard drive (more than 10MB) and DOS 5 or better there can be some very long wait times while DOS figures out how much space is available. I don't think that should be held against the FTP clients. :)

Is your FTP server slow and taking a while to start the initial connection? That is time the user would perceive as part of the transfer, but actually is not.

Mike
 
mbbrutman: Hmm .. I don't know why the times are so far off on your machine. ... Time is measured in the program starting after the file open but before any data is sent or received. ...
Click to expand...
It doesn't sound like there could be much lag there.
mbbrutman: Is your FTP server slow and taking a while to start the initial connection? That is time the user would perceive as part of the transfer, but actually is not.
Click to expand...
Hmm, you know, that part is suspect. Linux often finds little chores to do before it does what its told. (Thats why I prefer DOS - it's obedient :)) Anyway, I can't hold that against the client, as you say. In the end, regardless of who's fault it is, my concern as a user is how long it takes from when I hit return to when I see the prompt again.

On all the clients there is some delay from when I hit enter to when I see the prompt. This seems to vary from roughly 1.75 to 2.2 seconds in all cases. Your theory would seem to hold true, but could different client methods effect this?

Any way you look at it, your client is still 10-25% faster than LXFTP (and way faster than WFTP) on this setup. The actual transfer time, as you say, may be even faster yet. The overall wait times at this point are plenty short for a pleasant experience.
 
I run against Linux running vsFTP. It is a Pentium 233 with Fedora 2, which is slow by modern standards but it is far faster than it needs to be to run an FTP server. I doubt that a modern Linux machine ('modern' being anything better than a Pentium 133) would cause that much delay.

You can try PASSIVE mode - that might help. The command to select it is 'xfermode passive'. I would also try running a modern Windows command line FTP client to see if it suffers from the lag too.

The time that my code reports should be off by no more than 55 milliseconds - that's the resolution of the timer tick interrupt.

As for bugs, I'm hoping that you find nothing. I am especially careful with data transfer - there is no point in transferring data if it gets corrupted. But despite my hopes, alert me if you suspect anything wrong. And thanks for checking it out so quickly - it is nice to get instand feedback. :)

Mike
 
My server is set up to use the IANA registered epemeral ports 49152-65534 in passive mode (whatever all that means :)) as suggested in the docs. The 'xfermode passive' command works, but doesn't seem to make any difference. We have one machine here that sometimes runs XP so I'll try it from there to see if I can learn something. Anyway, as it stands, I'm happy with the way things are.

mbbrutman: And thanks for checking it out so quickly - it is nice to get instand feedback.
Click to expand...
I've never spent the big bucks on MSWin and associated programs (other than a second hand copy of DOS 6.2) because I made a concious decision not to go there. My software expenditures are almost nil, so when someone is writing software that might benefit me, and at no cost... I feel obliged to do what I can to help. :) I also always mention the programmers name (if known) when talking about software. I just think thats a simple matter of respect.

Thanks,
Ole
 
The usual way ...

ftp servername < ftpcmds.txt​

Put the userid, password and commands in ftpcmds.txt as you would type them in and it should work.

BTW, you had a 3.2MB file that you were transferring in about 3 seconds. (I think that was the receive rate.) At that speed you are doing 1MB/sec, which is just about line speed for a 10MB/sec connection. You are not going to get any faster with a P133 no matter what you used because we are burning a hole in the 10MB/sec card.

For people who have slower machines that are not maxing out the Ethernet card - you should notice that my FTP is faster relative to the other FTP clients. I'm not using as much CPU which makes much more of a difference on something like a 80286 or 8086.
 
mike - your client looks fantastic so far. i just did a speed test on my superport 8088 with the same file i used to test FTP v0.65. here are the results:

file size 921,600 bytes.
GET - 36.905 seconds (24.38 KB/s)
PUT - 33.990 seconds (26.47 KB/s)

and again the hard drive is MFM, the ethernet adapter is the xircom parallel.



i did another test on my tandy 1000tx, 8 MHz 286 but with an 8-bit data and memory bus. it has an intel etherexpress 8/16 card.

same file size:
GET - 15.510 seconds (59.42 KB/s)
PUT - 17.270 seconds (53.36 KB/s)
 
You must log in or register to reply here.
Back
Top