Closed Bug 791099 Opened 12 years ago Closed 8 years ago

Slow Internet Speed in Firefox 15

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Version:
15 Branch
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID
Tracking Flags:
Tracking Status
firefox15 - ---
firefox16 - ---

People

(Reporter: tdowner, Unassigned)

References

Details

https://support.mozilla.org/en-US/questions/936781

There are lots of reports of the Internet connection speed in Firefox being slow. Like users will actually go to a speedtest site, and get a slower speed than other browsers. This seems to be fixed by a variety of things (windows safe mode, Firefox Reset, etc.). But for some users none of these fix the issue.
We are seeing reports on SUMO from users that Flash is causing the slowdown. While I'm not entirely sure how that's possible, I figured I would bring it up:

https://support.mozilla.org/en-US/questions/936761#answer-367950
https://support.mozilla.org/en-US/questions/936862

Let me know if there is any additional information I can request from these users to help diagnose the issue.
F-Secure also seems to be causing issues with slow page loads. https://support.mozilla.org/en-US/questions/936510#answer-368184. Not sure if this is the same as the slow connection speeds (https://support.mozilla.org/en-US/questions/937314 is a new one today) but just a quick mention. F-Secure has caused these type of things before.
Keywords: qawanted
We did look into page load times on the whole post-FF15 release and didn't see anything out of the ordinary.

Let's follow up on the F-Secure lead with some QA testing.
Keywords: steps-wanted
QA Contact: jbecerra
I'll take a crack at this to do some network benchmarking with various security software and Firefox versions installed.
QA Contact: jbecerra → anthony.s.hughes
I've done some very unscientific testing using speedtest.net. My control test seems to indicate something is going on related to Software Update and Networking, but I don't know how that could be.

Methodology:
* Start with a clean Windows 7 SP1 64-bit installation
* Install Flash 11.4.402.278 (required by speedtest.net)
* Install no other software
* Run 3x speedtest.net with Internet Explorer 9 and take the average
* Run 3x speedtest.net with Firefox 14.0.1 and take the average
* Run 3x speedtest.net with Firefox 15.0.1 and take the average
* Run 3x speedtest.net with Firefox 15.0.1 updated from 14.0.1 and take the average

Results:
Internet Explorer 9
* ping: 55ms, download: 15.63mbps, upload: 5.84mbps
Firefox 14.0.1
* ping: 58ms, download: 9.00mbps, upload: 6.08mbps
Firefox 15.0.1
* ping: 58ms, download: 9.45mbps, upload: 5.59mbps
Firefox 14.0.1->15.0.1 update
* ping: 125ms, download: 13.70mbps, upload: 5.45mbps

As noted, this is very unscientific, but it seems Software Update is causing much worse ping times, though this does not seem to translate to dramatically worse bandwidth.

As mentioned earlier, this is just the control test; I've not yet installed any third-party software. I'll report back results with third-party software installed soon. However, at this stage, it might be useful to get Engineering involved to investigate in parallel.
Results with AVG 2013 + Internet Security Trial installed:
Internet Explorer 9
* ping:	72ms, download: 14.45mbps, upload: 6.03mbps
Firefox 14.0.1:
* ping:	72ms, download: 10.15mbps, upload: 6.36mbps
Firefox 15.0.1:
* ping:	79ms, download:	10.56mbps, upload: 6.41mbps
Firefox 14.0.1-15.0.1 update
* ping: 142ms, download: 15.29mbps, upload: 5.56mbps

Having AVG installed does seem to negatively impact network performance across the board (perhaps expectedly) and we see the Software Update anomaly again.
This seems to be an interesting find & I think we should file a separate bug to have engineers look at this particular case.

Was curious to see if you noticed any significant slowness in page loads , the reason this bug was originally reported for ?
(In reply to bhavana bajaj [:bajaj] from comment #7)
> This seems to be an interesting find & I think we should file a separate bug
> to have engineers look at this particular case.

Okay, I can file that later.

> Was curious to see if you noticed any significant slowness in page loads ,
> the reason this bug was originally reported for ?

No perceivable difference in page load times. I suspect that is far more dependent on bandwidth than ping times. Note that this "bug" only regresses ping time and not bandwidth. I'm not sure what affect worse ping times would have on the browsing experience.
:bajaj, please follow up with this on bug 795050.
See Also: → 795050
Results with F-Secure Internet Security trial installed:
Internet Explorer 9
* ping: 95ms, download: 8.77mbps, upload: 3.88mbps
Firefox 14.0.1
* ping: 82ms, download:	8.88mbps, upload: 4.70mbps
Firefox 15.0.1
* ping: 125ms, download: 15.25mbps, upload: 4.72mbps
Firefox 14.0.1-15.0.1 update:
* ping: 138ms, download: 13.55mbps, upload: 4.76mbps

It appears as though F-Secure also causes a network performance regression, though I would almost expect it to. However, the regression appears much more pronounced between Firefox 14.0.1 and 15.0.1. Keeping in mind that the regression in ping time does not necessarily translate to worse bandwidth. Will now test some page load times.
Anthony, thanks for looking at this. Weird report. I have no idea how update would play a role in that (nor am I especially certain that the numbers reported by a piece of flash are accurate).

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #8)

> No perceivable difference in page load times. I suspect that is far more
> dependent on bandwidth than ping times. Note that this "bug" only regresses
> ping time and not bandwidth. I'm not sure what affect worse ping times would
> have on the browsing experience.

ping times (RTT in network parlance) matter a LOT in real life. The smaller the document being transferred, the bigger deal RTT is because TCP grows the congestion window from slow start to real available bandwidth by a constant factor per RTT. Smaller RTTs mean you grow the window faster. So a large download is alive for many many rtt's and the window reaches full size fairly early on after which the rtt is unimportant to bandwidth.. but a smaller download is alive for a shorter period of time, and indeed it often isn't alive long enough even to reach the available bandwidth.. so the RTT totally dominates how fast it runs in practice. And HTTP/1 puts a rtt pause in between every transaction (and you might have 100 of them in a page load).

the flash page might be made up of a big chunk of data to calculate bandwidth, but a real web page is made up of dozens of much smaller objects so rtt matters a lot.

high rtt is the #1 reason mobile browsing can be painful. not lack of bandwidth.

Making bad rtt less painful is also the key idea in SPDY - so its an important topic.

This is a classic, and prescient, 15 year old rant on the topic http://rescomp.stanford.edu/~cheshire/rants/Latency.html

hth
Page load time test: CNN.com

Control (no third-party software):
* Internet Explorer 9: 11.2s
* Firefox 14.0.1: 4.0s
* Firefox 15.0.1: 7.7s
* Firefox 14.0.1-15.0.1 update: 4.6s

F-Secure installed:
* Internet Explorer 9: 6.2s
* Firefox 14.0.1: 4.7s
* Firefox 15.0.1: 5.7s
* Firefox 14.0.1-15.0.1 update: 3.5s

Page load times seem to indicate neither third-party software nor the software update issue (ie. worse ping times) have an impact on page load times. Of course, this is a very high-level, inaccurate, unscientific test. I think at the very least this warrants further investigation.

Please advise...
Something worth point out in comment 12 is that there does appear to be a page load regression between Firefox 14.0.1 and 15.0.1, though I think we need to do some more meaningful testing then simply loading a webpage and timing it manually.
Doesn't sound like there's anything actionable here. Untracking for release until something new comes up.
tracking-firefox15: + → -
tracking-firefox16: + → -
a user reported that he could solve the slow bandwidth issue by disabling "enhanced process monitoring" in f-secure advanced settings > computer > deepguard. apparently it interferes with adobe flash' protected mode. probably they use speedtest.net to measure the bandwith which also runs on flash.

https://support.mozilla.org/questions/940216
I'm not seeing this option in F-Secure's Internet Security or Anti-virus 2013 products and they've since taken down their previous versions so I cannot test this claim.
I'm dropping qawanted from this bug as QA is dead-ended here. If someone can provide steps to reproduce which include the latest Firefox release and the latest F-Secure software, that would be appreciated. Otherwise, I don't see that there is anything else we can do here.
Keywords: qawanted
i've tried it out myself now & it doesn't seem to be a problem in the current 2013 product. 

softpedia offers a download mirror for the 2011 version - http://www.softpedia.com/progDownload/F-Secure-AntiVirus-Download-14538.html - "enhanced process monitoring" is enabled in there by default & with this pref on i could reproduce the slow bandwidth measurement at speedtest.net (10-20% from what i'd expect from my normal line speed).
Thanks Philipp. That evidence seems to be fairly anecdotal, I'll see if I can manage to get it reproduced with that F-Secure version. Though this is likely a case of people just needing to update to the latest F-Secure product or communicating how to work around by disabling that feature.
There definitely seems to be a major network performance regression here but it's not related to Firefox 15.

1. Speedtest.net without F-Secure installed
> ping: ~5ms, bandwidth: ~12 mbps
2. Speedtest.net with F-Secure 2011 installed
> ping: ~190ms, bandwidth: ~2 mbps
3. Speedtest.net with F-Secure 2011 installed and EPM disabled
> ping: ~200ms, bandwidth: ~3 mbps
4. Speedtest.net with F-Secure 2013 installed
> ping: ~5ms, bandwidth: ~14 mbps
Results were similar for IE9, Firefox 14, and Firefox 15. I did not witness a performance regression between Firefox 14 and 15.

Based on these results I concur that the problem appears to be caused by F-Secure 2011 but it does not appear to be caused by the EPM feature. In other words, trying to use the workaround on SUMO of disabling EPM did not result in any benefit. Upgrading to F-Secure 2013 did remove this regression however.

At this point I think we can close this bug INVALID. I'm not sure what we can do to F-Secure users given the product upgrade is not a free upgrade.
Keywords: steps-wanted
i'd disagree that there is no benefit observable when disabling EPM.
 
i've also run a short unscientific test series (restarted the browser after each change to the settings) with f-secure 2011 on windows 7 64 bit and it shows a strong connection between flash protected mode (PM), F-secure enhanced process monitoring (EPM) & a slowdown on speedtest.net:

FF10 + Flash 11.4 + PM on + EPM off: 15ms, 7.7Mbps
FF10 + Flash 11.4 + PM on + EPM on: 115ms, 1.2Mbps
FF16 + Flash 11.4 + PM on + EPM off: 30ms, 9.9Mbps
FF16 + Flash 11.4 + PM on + EPM on: 156ms, 1.1Mbps
FF10 + Flash 11.4 + PM off + EPM off: 17ms, 9.7Mbps
FF10 + Flash 11.4 + PM off + EPM on: 62ms, 7.3Mbps
FF16 + Flash 11.4 + PM off + EPM off: 15ms, 10.2Mbps
FF16 + Flash 11.4 + PM off + EPM on: 16ms, 7.8Mbps
FF10 + Flash 10.3 + EPM off: 14ms, 9.9Mbps
FF10 + Flash 10.3 + EPM on: 14ms, 9.9Mbps
FF16 + Flash 10.3 + EPM off: 15ms, 9.9Mbps
FF16 + Flash 10.3 + EPM on: 5ms, 9.9Mbps

there probably isn't anything mozilla can do specifically here to address the situation, so the bug can be closed. however giving users the advice to disable EPM should help in many cases!
(In reply to philipp from comment #21)
> i'd disagree that there is no benefit observable when disabling EPM.

Sorry, I meant that *I* did not observe any benefit from disabling EPM.
invalid per comment 20
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.