Time remaining for XFER?

Come here to discuss FileZilla and FTP in general

Moderator: Project members

Post Reply
Message
Author
greggustin
503 Bad sequence of commands
Posts: 21
Joined: 2009-09-03 14:02
First name: greg
Last name: gustin

Time remaining for XFER?

#1 Post by greggustin » 2009-09-03 14:43

while each file in the Que has a estimate of time to Xfer
I cannot find a place it expects ALL to be done
eg - about 20 folders with about 100 documents each

User avatar
botg
Site Admin
Posts: 35491
Joined: 2004-02-23 20:49
First name: Tim
Last name: Kosse

Re: Time remaining for XFER?

#2 Post by botg » 2009-09-03 14:52

It's extremely difficult to give a reliable estimate of queue completion time. That's why it is not implemented.

greggustin
503 Bad sequence of commands
Posts: 21
Joined: 2009-09-03 14:02
First name: greg
Last name: gustin

Re: Time remaining for XFER?

#3 Post by greggustin » 2009-09-03 18:47

well - not that hard = as others do it
eg - look at total MB to be done
look at avg speed
do the math
(which is what I did by hand) -
after all - you do it for 1 file

but sure would be nice it have it displayed for 2100 files
IMHO

but thanks for timely reply

User avatar
botg
Site Admin
Posts: 35491
Joined: 2004-02-23 20:49
First name: Tim
Last name: Kosse

Re: Time remaining for XFER?

#4 Post by botg » 2009-09-03 19:16

The estimate for one single file is done AFTER the transfer has started, the time needed to setup the transfer is not included. The setup time can be significant however.

Due to the way FTP works, transferring 1000 files each 1KB in size can easily take twice as long (or even longer) as it would take to transfer just one file of 10MB in size.

It just is not possible to give a reliable estimate.

greggustin
503 Bad sequence of commands
Posts: 21
Joined: 2009-09-03 14:02
First name: greg
Last name: gustin

Re: Time remaining for XFER?

#5 Post by greggustin » 2009-09-03 20:10

yes - u r right
(many small longer than few big)
setup times are typicca;;uunder 2q sec
so, to add 1000 seconds not that hard ;P

thanks again for reply

ps

good program
just started using it today
am actually running it on my pals computer
through a remote access program

User avatar
botg
Site Admin
Posts: 35491
Joined: 2004-02-23 20:49
First name: Tim
Last name: Kosse

Re: Time remaining for XFER?

#6 Post by botg » 2009-09-03 20:20

setup times are typicca;;uunder 2q sec
so, to add 1000 seconds not that hard ;P
That would be extremely imprecise, could just as well roll a pair of dice or consult a stereotypical gypsy with a crystal ball.

Such imprecise estimates are just useless, remember how people are always complaining Explorer about its extremely wrong time remaining. The same would happen with FileZilla if I'd were to implement such imprecise estimates.

BTW: Your keyboard is broken :P

Magic3079
500 Command not understood
Posts: 1
Joined: 2010-03-07 09:41

Re: Time remaining for XFER?

#7 Post by Magic3079 » 2010-03-07 10:58

I just started using FileZilla in Linux and I like it so far. However, the total time would be really helpful. I'm not interested in super precize times down to the second. Please read on...

If the programming is not too difficult you could add something like: "rough time estimate". Of course this value will be not precize with many small files but who cares? When I transfer on my 100 Mbit LAN via FTP the times can vary when the LAN itself is slow at the moment, FileZilla will reflect that in the actual transfer speed. With the total time I'm interested if the transfer takes 15 Minutes or 3 hours. Every FTP user should understand, that such a "total time estimated value" cannot be accurate down to the last second!!

annunaki2k2
500 Command not understood
Posts: 1
Joined: 2010-09-14 09:58
First name: Russell
Last name: Knighton

Re: Time remaining for XFER?

#8 Post by annunaki2k2 » 2010-09-14 10:11

Can't help but agree with this as a feature requirement - this is something that would be very advantageous regardless of how inaccurate/imprecise it is; after all some feed back is better than none at all. One idea to cater for this would be to have a time estimate for an entire folder in the transfer queue rather than per file within that folder.

minorgod
500 Command not understood
Posts: 1
Joined: 2012-10-23 23:13
First name: Brett
Last name: Brewer

Re: Time remaining for XFER?

#9 Post by minorgod » 2012-10-23 23:49

I just went looking for a way to get an ETA on my transfer queue and was shocked to find only old forum threads such as this one saying it wouldn't be implemented. Is this really still not implemented?!! Not trying to start an arguement here, but I have a very hard time believing it's not possible to implement considering it's implemented in at least one other FTP client I've used. Considering how talented the programmers of Filezilla clearly are, this seems like it should be pretty trivial to implement, even when taking the FTP setup times into account. If there's more than a few files in the transfer queue, simply wait to display an ETA until you've had enough connects to determine a running average and then use that as a fudge factor. If there's only a few files in the queue, just skip the fudge factor and tack a second or two onto the ETA. No one is going to care if the ETA is not 100% accurate, it's an estimate, hence the "E" in "ETA". It's just a matter of keeping running average of overall transfer speeds, ftp setup times, and total bytes remaining for all files in the transfer queue. If you wanted, you could even display the ETA in two parts, such as:

ETA: 1,520,000 kb remaning @ avg transfer speed 500k/sec = 50.66minutes
Average Setup Overhead: .1 sec * 50,000 files remaining = 83 minutes
TOTAL ETA: 3.23 hrs

And if you wanted to take multiple simultaneous connections into account you could just divide the setup overhead by the number of simultaneous connections allowed. I don't know if I did the above math right, but you get the picture. The total ETA could be shown in the status bar and then a tooltip could pop up on hover that showed the full ETA calculation info for better clarity.

Anyway, thats my two cents. My queue of 50,000 files is done downloading now, so back to work for me.

sh0az
500 Command not understood
Posts: 1
Joined: 2014-05-17 20:35
First name: Shon
Last name: Balis

Re: Time remaining for XFER?

#10 Post by sh0az » 2014-05-17 21:08

botg wrote:
setup times are typicca;;uunder 2q sec
so, to add 1000 seconds not that hard ;P
That would be extremely imprecise, could just as well roll a pair of dice or consult a stereotypical gypsy with a crystal ball.

Such imprecise estimates are just useless, remember how people are always complaining Explorer about its extremely wrong time remaining. The same would happen with FileZilla if I'd were to implement such imprecise estimates.

BTW: Your keyboard is broken :P
First of all since this is my first post, i want to thank you for a otherwise great ftp client.

But i'll have to add another vouch for implementation of total ETA...

It works pretty well in every other FTP program i've used, not sure why you believe it would be "extremely imprecise".

Apart from the drop on the last file in queue because of no multithreaded downloads, my download speed is otherwise stable from any FTP i use, so it would be pretty accurate to do average speed of x secs/mins compared to data size left as suggested above.

In reality the difference will be a couple of minutes added or subtracted compared to the real transfer time, and sure is better than nothing in this case if you ask me.
Especially since Filezilla doesn't display the remaining queue datasize in realtime either.

It should be a walk in the park to implement, if anything you could always make it an optional setting.

Himeko
500 Command not understood
Posts: 1
Joined: 2016-04-04 07:10

Re: Time remaining for XFER?

#11 Post by Himeko » 2016-04-04 07:19

Wow, 7y old thread, guess I was being delusional even googling for this thinking maybe I missed a setting somewhere.

Sure it's not 100% accurate.. but you should still be given a hint. Think i.e when you are transferring only big files, the overall ETA would then be quite accurate. As of typing this I'm moving game files from my PS3 to my PC over LAN, most of it are huge files, an eta here would be off for maybe a couple seconds max (besides extremely low latency in between FTP commands).

Image
Last edited by boco on 2016-04-04 09:27, edited 1 time in total.
Reason: Please use the Imgur https:// link, since the forum runs on HTTPS, too.

arfyness@arfy.org
500 Command not understood
Posts: 1
Joined: 2019-02-08 17:12
First name: Nate

Re: Time remaining for XFER?

#12 Post by arfyness@arfy.org » 2019-02-08 17:35

I agree it would be generally helpful for a lot of people to have some sort of guess, even if it was off by a fair amount. Any time remaining estimate can only be a guess.

I have some thoughts for a method that I think would be accurate enough for most of us who are interested in seeing this info.
Here is my suggestion, it is what I would implement as an experimental feature if I were getting requests for estimated time remaining for the whole queue.

Track the amount of time between STOR (or RETR) and the start of the file transfer.
Save this value for the last 5 transfers or so; from there calculate the current average start up time.
Calculate the current average transfer speed (over the last 15 seconds or so)

Calculate est remaining start up time: Multiply the number of files remaining by the average start up time.
Calculate est remaining transfer time: Multiply the number of KB remaining by the time it takes to send each KB.

Add those two est remaining times together to generate an estimate the total time remaining.
Obviously in the case for the first few transfers, you'd have less than 5 to generate the average, so use what you have.
I can understand how it would be complex to implement this for queues containing more than one server, so perhaps it would be limited to queues containing only one server.

Personally I'd be quite happy even if there were an experimental option we could enable, which allows to show SOMETHING in the way of estimated time remaining. It wouldn't have to enabled by default, and could even have a big disclaimer that it cannot be precise, so don't complain if it turns out incorrect, and don't make any important plans based on the value returned by that option.

And with all that said, having read through the posts here spanning many years, I distinctly get the feeling it's probably just not going to happen.

-Nate

Post Reply