447609 - Time left until download complete, as shown in the status bar, is wrong for multiple downloads

Status: UNCONFIRMED

(Toolkit :: Downloads API, defect)

Description

[Oliver Grbavac]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1

If multiple downloads are in progress at the same time, the remaining time until all downloads are complete is shown in the lower right corner of the Firefox Browser Window.

This time is calculated wrong. It shows the sum of the remaining time of all downloads and does not divide this sum with the number of active downloads.

Example:

There are 4 downloads active, each 100MB in size. Remaining time for each download is about 30 mins.

The status in the browser - lower right status line - shows the sum of all remaining times, which is 2 hours and does not divide the sum of remaining times by 4.

Reproducible: Always

Steps to Reproduce:
1. start several downloads at the same time
2. take a look at the browser window, lower right
3.
Actual Results:  
See Bug details


-

Comment 1

[Stephen Donner [:stephend] Not actively reading bugmail]

I can't reproduce this; in my experience, it takes the longest-time-remaining download.

Comment 2

[Stephen Donner [:stephend] Not actively reading bugmail]

Attachment: Screenshot

Comment 3

[Stephen Donner [:stephend] Not actively reading bugmail]

Oliver, can you please take a screenshot of it doing otherwise, and attach it here?  Thanks!

Comment 5

[ian.cheong]

File sharing sites for free users may be part of the problem. Other reports here. My MacOS machine reports 10 mins at start of a download and speed in line with that but takes about 40mins. Chrome reports a much slower speed.

http://support.mozilla.com/tiki-view_forum_thread.php?locale=en-US&comments_parentId=383680&forumId=1

Comment 7

[Nickolay_Ponomarev]

I believe this information was removed from the main browser window a while ago, so this issue does not exist anymore, right?

Comment 8

[Eric Wertz]

It's unfathomable that this problem hasn't been fixed in more than a decade. While it may have been less noticed many years ago, nowadays there's no excuse for not recognizing that this problem still exists. It's trivial to reproduce, and trivial to explain why it's happening, and why it's doing the wrong thing. The problem also has nothing to do with multiple downloads -- or, at least it hasn't been a necessary precondition for many years, if it ever was.

Downloads can be throttled in any number of ways, in all of the same ways that anyone that's ever taken an operating systems course understands -- time-slicing.

If the server wishes to limit download speeds to 100kB/minute, it lets the download proceed for as long as it takes to give the user his/her/shim/sher/it/they/zem/ziggle/foo/bar/baz/mumble 100kB, then it stalls until the next, fresh minute comes around. If the download pipe supports getting the 100kB in four seconds, then the download will stall for 56 seconds, after which the next 100kB parcel will get blasted out in short order, etc. Lather, rinse, repeat, until the download completes. If the file is 1MB, then the transfer will take 10 minutes. In the real world, the period of these bursts is on the order of 20-30 seconds, probably to decrease the likelihood of tripping over some timeout value somewhere in the 7-layer ISO networking burrito.

It's obvious after spending five minutes watching this go on that what's happening on is that the download time is ends up being estimated according to the rate at which the file would be transferred ONLY WHEN THE TRANSFER IS GOING ON, with complete disregard to wall-clock time. In the scenario above, the time estimate is based on a throughput of 100kB/4s (25kB/sec) rather than 100kB/60s (1.67kB/sec).

One can readily see what the download quanta is during a download of more than a few minutes -- 1MB bursts in 3 seconds aren't unusual, then the download naps for 20 seconds, then wakes up again -- over and over again like (wall-)clockwork.

It's NORMAL for download estimates to be off by factors of 10-20x. It's as reproduceable as bad breath in the morning.

The only things that are not clear is how the implementation EVER fell out this way, and why this problem seems to have existed from Day One and still exists. I've seen references to download time estimation being wrong for 17 years in other bug reports in this database. FTP has managed to do download estimation reasonably well for ~40 years, so The Science suggests that this problem is solvable, but that The Engineering is lacking.

FFS, please fix this. I'm sick of waiting "just a couple minutes" for a download to complete in an hour.