On Thu, Mar 11, 2004 at 12:25:33PM +1300, farr_at_metservice.com wrote:
> At 11:58 AM 3/11/2004, you wrote:
> >The first thing, ftp is an inherently slow protocol. That's why you'll
> >notice curl has special support to add additional timeouts for FTP because
> >FTP is notoriously slow. The other thing, when you are comparing Linux and
> >Windows, is this the same machine (i.e. dual-boot)? I mean, if you're
> >comparing your Windows machine on a 56K and say a Linux shell account on a
> >T1, well then obviously the Linux download is going to be faster :)

> They are on the same subnet plugged into the same switch. The windows box
> is a P4 3.2G and the linux box is a P3 1G, they have the same intel network
> card. It is a 100mbit switched network. FTP might be slow ... but that is
> just rediculous.

FTP's problem is that it establishes a new TCP connection (with its 3-way
handshaking) for every file; SMB uses the same TCP connection. That can
account for twice as many packets flowing across the wire in your case,
and all those extra packets have to be acknowledged individually. There's
nothing you can do about this part of the problem (short of dropping ftp).

The other thing to look into is your ftp server configuration. Servers can
be configured to do reverse DNS lookups on incoming connections, as well as
doing ident (RFC 1413) lookups, both of which could slow things down (although
I would hope those are done at login only and not once per file). Of course,
I assume you're reusing the ftp control channel and aren't logging in
anew for each file.

>>> Dan

-- 
http://www.MoveAnnouncer.com              The web change of address service
          Let webmasters know that your web site has moved