81857 - Saving File Dialog "at xx kBit/s" shows overall average speed

Status: RESOLVED FIXED

(SeaMonkey :: Download & File Handling, enhancement)

Description

[Peter Asemann]

In my humble opinion the "Saving File" Dialog visible while downloading should
show the actual speed of the download, not the average speed. As it is now, it
shows the average total speed until the very moment the value is displayed.

If this has been implemented that way on purpose, trash this bug report.

If not, maybe you don't believe that the average is displayed, though, but I
have some proof:

I have ISDN with the possibility to activate the second channel while downloading.
I also have a tool showing the through-put of the ISDN channels.

When I activate the 2nd channel when I already downloaded the half of a file,
the value displayed at the field Progress: xx % complete "at xx kBit/s" does
only raise very slowly, while the through-put indicator software shows that the
throughput has doubled, and the "time left" field drops rapidly until it reaches
about half the value before activating dual channel transfer.

I can imagine that someone made the file progress dialog showing the average
download speed, because maybe the "time left" value is calculated based on
average speed to be less dependent on fluctuation of the transmission speed.

Well, I think the "time left" should be calculated on average speed, but the "at
xx kBit/s" value should be the real actual through-put.

Comment 1

[Junk_HbJ]

Sounds somewhat similar to bug 78048.

Comment 2

[Doug Hanley]

Attachment: patch that provides instantaneous rate info to download progress

Comment 3

[Doug Hanley]

Funny, I actually made this functionality on my own build, but I didn't think
anyone would want it. I've attached the patch. It affects downloadProgress.js,
downloadProgress.xul, and downloadProgress.dtd in components/xfer. Keep in mind
that this is my first time so dont go to **** me.

Comment 4

[timeless]

hrm

Comment 5

[Matthew T (active 1999-2002)]

Firstly, do we use this rate to calculate the time remaining for a download, or 
does that use different code entirely? I.e., how important is the transfer rate 
in the grand scheme of things?

Secondly, how instantaneous is `instantaneous'? From my ignorant reading of the 
code, the patch appears to calculate the transfer rate based on the past second 
-- is that correct?

The shorter the time period we use to calculate the rate, the more it will jump 
around, so the less useful it will be. But the longer the time period we use to 
calculate the rate, the less it will adjust to permanent changes in rate (such 
as flicking the ISDN switch, or finishing another download), so the less useful 
it will be.

I think as a balance between these two, we probably want to use a weighted 
(logarithmic?) system -- one which takes into account transfer rates over the 
whole time the download has been in progress, but which gives progressively 
more weight to more recent rates. Of course, we don't want to have to build up 
a vast database of rates as the download goes on, just for the purpose of 
recalculating the transfer rate after every second ... Any mathematicians here?

Comment 6

[Doug Hanley]

The patch I made calculates the download speed approximately every second, so
the word instantaneous is really a misnomer, sorry.  And the time left is still
calculated on the average speed, I though that would be most appropriate since
its quite annoying to see the time left flying all over the place.

I kind of like the weighted scale idea, but it might still have a tendency to
creep up (or down) to the actual download speed, albeit faster.  Plus, I am no
no mathemitician so I wouldn't know how to do it.

Also, it might be nice to add some code that detects huge jumps in download
speeds, to see if the download stalled or if the ISDN switch flicks on, and
adjust accordingly.

Finally, maybe we could take an average of the speeds for last few seconds (say
4 or so) and use that.

Personally, I would prefer a method which leans more toward a recent rate than
an overall average, but thats just me.  I still like the idea of having two d/l
rates, one average and one recent, but that might be too confusing to an end
user.  Any thoughts?

Comment 7

[Peter Asemann]

I have thought about if exponential smoothing could be used to calculate the
transfer rate to display, but as it is rather a method to predict the upcoming
transfer rate, this really makes no sense, as well as weighting the transfer
rate of the last second more than the one of the second before last, as the
transfer rate hopping is not really predictable, so there's no reason why the
transfer rate in the actual second should more probably be like in the past
second than like in the second before last.

That's why I think the average of the last 4 or 5 seconds would be a good
compromise.

Comment 8

[Doug Hanley]

Attachment: provides average download speed in 4 second intervals

Comment 9

[Doug Hanley]

btw, in the code I wrote, you can change the number of seconds the average spans
by changing the variable timeFrame in downloadProgress.js.  Also, the download
might crash due to an unrelated bug in the disk cache, bug 81907.  If this
happens either get a new build or disable disk cache in prefs.

Comment 10

[Jonas Jørgensen]

.

Comment 11

[Michael Gabriel]

*** Bug 182391 has been marked as a duplicate of this bug. ***

Comment 12

[Az]

IMHO, the current speed shown should be just that, _current_; so 4 seconds is 
too great a time phase.  Other figures in the dialogue box seem to update once 
a second so surely this would be a suitable time phase ?

Also, should I file this under a different bug number for Firebird or will 
this patch fix both ?

Comment 13

[Christian :Biesinger (don't email me, ping me on IRC)]

nsProgressDlg.js isn't forked, afaik, so a patch would fix both seamonkey and
firebird.

Comment 14

[chris hofmann]

to late for features and UI changes in 1.6; this will be good to get early in 1.7

Comment 15

[Asa Dotzler [:asa]]

not going to block the release for this feature request. If a reviewed patch
lands before the freeze, great. If not, then please request drivers approval for
any fully reviewed and tested patches that become avialable during the freeze.

Comment 16

[Boris Zbarsky [:bzbarsky]]

This probably needs review from someone UI-related....

Comment 17

[timeless]

Comment on attachment 35535 [details] [diff] [review]
provides average download speed in 4 second intervals

i can't imagine this is l10n safe

Comment 18

[Asa Dotzler [:asa]]

*** Bug 228196 has been marked as a duplicate of this bug. ***

Comment 19

[Lorenzo Colitti]

What about not changing the UI and only changing the code that calculates the
download speed from "average since the beginning" to "average of last 4 seconds"?

I think it would be a good idea to use this to calculate the time left too:
average performance over the last 4 seconds is much more indicative of future
performance than average performance since the download started (and this is all
the more true if downloads are paused/resumed, of course).

Comment 20

[Az]

hey doug, how about requesting review on that patch ?

Comment 21

[R.K.Aa.]

*** Bug 242210 has been marked as a duplicate of this bug. ***

Comment 22

[David Balažic]

There is a bug with current code. Sometimes ( can reproduce anytime ) it
displays megabytes of speed on a line that is hardlimited to 100 kilobytes. So
it must be changed, one way or another. IMHO, the average over last few seconds
should be showed during download and the overall average after it finished (
currently nothing is displayed after the download finishes ).

P.S.: There is not such thing as "current speed". Well there is, but is is
either 0 kbps or the hardware speed of you line, both pretty useless as a statistic.

Comment 23

[Jo Hermans]

*** Bug 243283 has been marked as a duplicate of this bug. ***

Comment 24

[Justin Kerk]

See also Firefox bug 245725

Comment 25

[Prognathous]

*** Bug 260983 has been marked as a duplicate of this bug. ***

Comment 26

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 27

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 28

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 29

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 30

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 31

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 32

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 33

[[e-mail]]

If not already fixed somewhere else that I didn't notice, this was fixed by the switch to toolkit download manager (bug 381157), which I believe computes a decaying average speed.

Comment 34

[chAlx]

Unfortunately the problem wasn't fixed in bug 381157: there's still incorrect download speed after pausing and resuming download (see blocked and forgotten bug 151810).

I'd suggest to close this bug, delete all its unresolved links and open new page in history of this simple speed calculator. And fix it recently ;)

PS: Steps to reproduce (checked with the dialog enabled instead of download manager):
1. Start to download a large file.
2. Wait for half of it to be done, then click "pause" button.
3. Click "resume" button.
See: Dialog download speed is too high (usually more than connection speed): it 'thinks' the first half part has been just downloaded in a moment.

--
Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1pre) Gecko/20090615 SeaMonkey/2.0b1pre

Comment 35

[chAlx]

Sorry about testcase: it's Cancel/Retry combination, not Pause/Resume.