Closed Bug 478578 Opened 17 years ago Closed 10 years ago

On Firefox nightly updates, the download speed is significantly miscalculated

Categories

(Core :: Networking, defect)

1.9.1 Branch
x86
Windows Server 2003
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: zurtex, Unassigned)

Details

Attachments

(1 file)

STR: 1) On the 1.9.1 Branch, download a software update 2) The download speed is calculated as some very low bytes per second when the download is completed in only a few seconds. Expected results: Correct download speed.
Flags: blocking-firefox3.1?
Flags: blocking-firefox3.1?
Attached image Screenshot of updater
As you can see here, very low download speed shown and very high estimated time. The download was actually completed in about 5 seconds.
Component: General → Application Update
Product: Firefox → Toolkit
QA Contact: general → application.update
Version: 3.1 Branch → 1.9.1 Branch
These values are provided by nsIncrementalDownload and not app update so over to core networking
Component: Application Update → Networking
Product: Toolkit → Core
QA Contact: application.update → networking
Don't know if it's related, but yesterday I burnt the contents of my Vista desktop, with lots of firefoxes on it, to a dvd, first it said it would take 20 minutes, but while burning it told me it would take more than 20 days.
(In reply to comment #3) > Don't know if it's related, but yesterday I burnt the contents of my Vista > desktop, with lots of firefoxes on it, to a dvd, first it said it would take 20 > minutes, but while burning it told me it would take more than 20 days. I think that is because of the OS and has nothing to do with Firefox.
> Platform: Windows Server 2003 > 1) On the 1.9.1 Branch > 2) The download speed is calculated as some very low bytes per second when the download is completed in only a few seconds. Mismatch between change by Bug 454990 and download manager? Bug 454990 has increased TCP send window size on Windows, with introducing new prfs. > +// The default TCP send window on Windows is too small, and autotuning only occurs on receive > +pref("network.tcp.sendbuffer", 131072); It's different from (larger than) usual MS Win's default TCP window size. It may be used in receive too, because Bug 454990 changes SocketTransportService.
I didn't get this problem on a full download of Firefox, but then next update was a partial one and I got the problem again then.
I had this same problem when automatic upgrading from Firefox 3.5.4 to 3.5.8 with Windows XP SP3.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: