Time remaining for XFER?
Moderator: Project members
-
- 503 Bad sequence of commands
- Posts: 21
- Joined: 2009-09-03 14:02
- First name: greg
- Last name: gustin
Time remaining for XFER?
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
I cannot find a place it expects ALL to be done
eg - about 20 folders with about 100 documents each
Re: Time remaining for XFER?
It's extremely difficult to give a reliable estimate of queue completion time. That's why it is not implemented.
-
- 503 Bad sequence of commands
- Posts: 21
- Joined: 2009-09-03 14:02
- First name: greg
- Last name: gustin
Re: Time remaining for XFER?
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
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
Re: Time remaining for XFER?
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.
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.
-
- 503 Bad sequence of commands
- Posts: 21
- Joined: 2009-09-03 14:02
- First name: greg
- Last name: gustin
Re: Time remaining for XFER?
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
(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
Re: Time remaining for XFER?
That would be extremely imprecise, could just as well roll a pair of dice or consult a stereotypical gypsy with a crystal ball.setup times are typicca;;uunder 2q sec
so, to add 1000 seconds not that hard ;P
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
Re: Time remaining for XFER?
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!!
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!!
-
- 500 Command not understood
- Posts: 1
- Joined: 2010-09-14 09:58
- First name: Russell
- Last name: Knighton
Re: Time remaining for XFER?
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.
-
- 500 Command not understood
- Posts: 1
- Joined: 2012-10-23 23:13
- First name: Brett
- Last name: Brewer
Re: Time remaining for XFER?
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.
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.
-
- 500 Command not understood
- Posts: 1
- Joined: 2014-05-17 20:35
- First name: Shon
- Last name: Balis
Re: Time remaining for XFER?
First of all since this is my first post, i want to thank you for a otherwise great ftp client.botg wrote:That would be extremely imprecise, could just as well roll a pair of dice or consult a stereotypical gypsy with a crystal ball.setup times are typicca;;uunder 2q sec
so, to add 1000 seconds not that hard ;P
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
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.
Re: Time remaining for XFER?
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).
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).
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.
Reason: Please use the Imgur https:// link, since the forum runs on HTTPS, too.
-
- 500 Command not understood
- Posts: 1
- Joined: 2019-02-08 17:12
- First name: Nate
Re: Time remaining for XFER?
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
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