Re: ftp method

[Jason Gunthorpe <jgg@gpu.srv.ualberta.ca>]

On 8 May 1998, Manoj Srivastava wrote:

> 	I just tested dslect update with ftp.debian.org in my
>  sourcelist, and things went fine. I am downloading for dselct
>  install, so I think this baby works.

I've been fiddling with it, first off this test:

va{root}~/work/deity/methods/ftp#./ftp
ftp://llug.sep.bnl.gov/debian/README t
ftp://llug.sep.bnl.gov/debian/README t2
F ftp://llug.sep.bnl.gov/debian/README
I Connecting to llug.sep.bnl.gov
I Set type binary
L Already have t with size 1057
F ftp://llug.sep.bnl.gov/debian/README
I Connecting to llug.sep.bnl.gov
I Set type binary
S 1057
I Downloading
M 99e7acd0783cfb1b29de5d09c761241a  

It prints 'I Connecting to llug' twice, if it doesn't actually reconnect
it shouldn't print this, and if it does actually reconnect then it
shouldn't :> Similarly it should not reset the type to binary if it isn't
reconnecting.

Second after I do the above and then 'touch t' I get,

va{root}~/work/deity/methods/ftp#./ftp
ftp://llug.sep.bnl.gov/debian/README t
ftp://llug.sep.bnl.gov/debian/README t2
F ftp://llug.sep.bnl.gov/debian/README
I Connecting to llug.sep.bnl.gov
I Set type binary
S 1057
I Resuming (1057)
M 99e7acd0783cfb1b29de5d09c761241a
F ftp://llug.sep.bnl.gov/debian/README
I Connecting to llug.sep.bnl.gov
I Set type binary
L Already have t2 with size 1057 

Notice it tried to resume. This is wrong, it must not resume if the date
is not exactly equal to the remote side.

Another observation is that it does not seem to print that it is
requesting the modification time, that is variable time and should be
printed out. Also after connecting it should probably print 'I
Authenticating'

Also for interests sake, do you compute the MD5 as the file downloads or
after it is done? (I'm guessing after the fact from my tests) If so you
should print out 'I Computing MD5'. I will change things so that when
things reach 100% the display shortens a bit.

Resuming an aborted file seems a bit glitchy, I think there is something
wrong.

I got his report,

3%  [Packages `Resuming (200020) ' 112420/334k 33%] 842M/s 0s 

As you can see it didn't actually resume, but claimed too :< It's kinda
neat that it thinks it is getting 842M/s too :> (negative growth I think)

Remeber, it must -never- resume a file that is in ../ , it doesn't
actually resume, but it seems to claim to. Files in ../ are provided only
for date comparision to see if it should be fetched at all.

I get good performance numbers, about 170k/s peak from llug, this is about
the limit of their ftp server. My tests with http show it peaks about the
same.

FTP:  Fetched 17.3M in 2m20s (123k/s)
HTTP: Fetched 17.3M in 1m50s (156k/s) 

Those numbers are total elapsed time, they include the time to generate
the md5 hash, connect to the server and so on. So yes, as I have been
saying http is faster. ~6-7s of the difference is due to the fact that
'http' computes the md5 on the fly.

Worst case tests, (http without pipelining) on 45 files gives

FTP: Fetched 14.3M in 3m24s (69.7k/s)
HTTP: Fetched 14.3M in 1m54s (125k/s)
 
All I can say here is Yikes! That is a substantial difference.

Jason


--
To UNSUBSCRIBE, email to deity-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org