User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9) Gecko/2008051202 Firefox/3.0 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9) Gecko/2008051202 Firefox/3.0 Sometimes the speed of the download falls to zero, as properly indicated by the Download Statusbar Add-On. However, on the Download Manager, the speed indicates the last non-zero speed. If one does not have the D-Statusbar addon installed, or is looking only at the Download Manager, you would not know that your download has stalled. Reproducible: Always Steps to Reproduce: 1. As a proxy, install Download Statusbar Addon: https://addons.mozilla.org/en-US/firefox/addon/26 2. Restart Firefox 3. Download a reasonably large file 4. When progress is halfway through and clearly still active, unplug ethernet/turn off wireless/turn off modem 5. Observe that progress indicator on FF Download Manager stops, but indicates a non-zero speed. Download Statusbar indicates zero speed as expected. Actual Results: Download Manager indicated non-zero speed in middle of file download when there is no internet connection. Expected Results: Speed indicator should be zero.
Firefox 3.6 still can be stalled with the lastest download speed instead to show a null activity. After a while, the user must be warned a download has stalled. More, some websites didn't allow a resume, so it must important to warn him.
When hang, download speed is Totally incorrect, as bug 807084 says. This bug is from 2008 and still nobody bothered to fix it. "inaccurate" sounds like a small problem, but it is not the case. The title of The bug is misleading. "inaccurate" should be replaced with "totally incorrect".
There's two related situations here: 1) If the download fully stalls it continues to report the last known speed and time estimate indefinitely, thus giving no indication that it has stalled. 2) If the download stalls intermittently it only reports a speed when it has one, thus giving a higher than true speed and an underestimated time to completion. I've seen way too many downloads with more stall time than download time and the result is a bogus download speed and an estimated remaining time that is wildly shorter than it's really going to take.
(In reply to Dave Garrett from comment #6) > 2) If the download stalls intermittently it only reports a speed when it has > one, thus giving a higher than true speed and an underestimated time to > completion. That's the case with Uploaded.net / Ul.to, a rather popular file host. To test, download any large file without logging in.
(In reply to :Paolo Amadini from bug 1281668, comment 1) > We use a simple algorithm to calculate the download speed and it may definitely have > some limitations like the one you described. [...] if you have any example of other > programs or algorithms doing a better job in the case you described, we might > definitely investigate and adopt them. Opera 45.0.2552.888 doesn't have this problem (I don't know whether it's something they developed on their own or inherited from Chrome). Though Opera never shows a speed of 0 bytes/s on the Downloads panel, on the Downloads details tab it flips back and forth between 0 bytes/s and non-zero bursts. Another example I've come across is Uploadgig.com.
A nice, open source example should be available in 'scp' (secure copy, part of 'ssh' I believe). It shows percentage and kB downloaded, download speed, and ETA. Download speed updates about twice each second. Download speed tapers to 0 if the transfer is held, and reaches 0 after about 5 seconds. This makes me suspect that it simply maintains a record of the last 10 measurements (at 2/second), and shows the average of those values.
Firefox currently uses exponential smoothing which is a very good strategy, but two changes need to be made: 1) To handle stuck downloads, DS_setProgressBytes should be called periodically, even when there is no new data. It could be called at a fixed interval, or with exponentially increasing intervals to save battery life. The interval should be reset to a small value whenever new data is received. 2) To handle bursty downloads, the smoothing factor must take the length of the update interval into account so that the smoothing time constant remains constant. In DownloadCore.jsm, change this.speed = rawSpeed * 0.1 + this.speed * 0.9; into let k = Math.pow(0.9, intervalMs / kProgressUpdateIntervalMs); this.speed = rawSpeed * (1-k) + this.speed * k; The algorithm is duplicated in urlbarBindings.xml, so do the same thing there.