Based on that dump, it looks like it's a networking stack problem. The
client ACKs the close of the passive data connection in packet #20, but
waits a further 195 ms before ACKing the server's "150" response code
in packet #13. This is probably due to "delayed ACK" behaviour in the client.
Try disabling delayed ACK and see if that helps (see
http://www.jsiinc.com/SUBC/tip1400/rh1424.htm for Windows).

This packet trace reminds me of another enhancement that was discussed on this
list some months ago, and I guess was lost. Curl sets the directory before
transferring each file, even if the directory didn't change. Fixing that
in libcurl would shave a few more ms off the transfer time.

>>> Dan

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