Calculate by average speed

A far more accurate est. time could be calculated by using average speed instead of what it currently does, which seems to be based on the current speed over a few seconds. Is there any chance of an option for this?

Also could an option be added to display average speed instead of current speed in the title bar?

>> A far more accurate est. time could be calculated by using average speed instead of what it currently doe
You are really wrong.
Eg.: A current progress is 80% - 100MB file is being downloaded 80% of size during 1 hour with a speed of 2kB/s.
What's an estimate time for your suggestion?
Suddenly, server is returning a data with a speed of 300kB/s.
What's your estimate time now? It almost didn't change its value!
Now compare what's more accurate - your suggestion or what FRD does. I hope it's more obvious now. You can never use global avg speed for counting est. time.

>>Also could an option be added to display average speed instead of current speed in the title bar?
We will consider that.

-------------------------------------





Edited 3 time(s). Last edit at 01/24/2011 07:18AM by Vity.

For question 1: True in that case that the average speed/eta won't change a lot quickly, if it sustained 300 KB/s till it finishes eta would go down and avg speed would go up in huge steps. In that case I agree the current eta system would be more beneficial. But I've never ran into anything like that although I often see these 2 cases.
Example A: Speed jumps between 0 and 500 KB/s every few seconds, average speed is 200-250 KB/s. hotfile, fileserve, filesonic usually do this.
Example B: Speed jumps from 100 KB/s to 3 MB\s (my max) every few seconds. megaupload and megashares often does this.
In both cases the est time's are all over the place especially in Case A: where it jumps from hours to minutes/seconds. Average speed would give a pretty good eta within 10 seconds in each case. If FRD is using server replies for speed that could be the main culprit of my examples and calculating by data transfer in a certain amount of time could solve it. Another idea that might work great for both of our examples is polling less often, say 10 seconds after the initial 10 seconds. I believe this is how most transfer programs work but I've never seen any eta jump around more than FRD does.

2. Thanks for the consideration :)