474204 - Firefox utilizes all bandwidth when uploading a file, other apps are 'blocked out'

Status: RESOLVED INVALID

(Core :: Networking, defect)

Description

[Jelle Geerts]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5

When uploading a file to e.g. Gmail (as attachment in an e-mail), other applications like Pidgin can't contact the internet anymore. Pidgin for instance disconnects from IRC servers etc.

Reproducible: Always

Steps to Reproduce:
1. Use a form to upload a file -that takes some time to upload- somewhere (e.g. Gmail).
2. Wait until other applications are 'blocked out' (i.e. can't contact servers).

Actual Results:  
Other applications don't work like normal while Firefox is uploading a file that takes time to upload.

Expected Results:  
Other applications should continue to fully function like normal while Firefox is uploading files.

Comment 1

[Jo Hermans]

Isn't that problem in the OS ? I mean, it shouldn't matter if a process takes 100% cpu and wants all available bandwidth. Every process should get a chance in a multitasking OS - it's not really possible to block another process on purpose.

What type of internet connection are you using ? ADSL ? That has a rather low upload limit. Do you also see the problem on downloading ?

Comment 2

[Jelle Geerts]

There seems to be no problem when downloading. I'm using an 3072/512 ADSL line.

I agree that it shouldn't matter whether an application wants 100% cpu and bandwidth, but you can't file bugs for Windows XP ;) So, we might need a workaround...

Comment 4

[Matthias Versen [:Matti]]

I assume that you are using a router then it's the router that does a bad job. here. There is no right way for an application to do QoS.

If you don't use a router then it's XP TCP/IP stack.
That you can't file bugs on something doesn't mean we have to find impossible workarounds.

This is wfm with win2k, windows2003 and vista with a Openwrt router and 3072/512 ADSL 

marking invalid as this is not a bug in Gecko and there is no right way to guess the currently available bandwidth and throttle below that.

Comment 5

[Jo Hermans]

Actually, Matti, it's not possible for the router to do a good QoS either. I know, I have been working on QoS protocols, and about the only thing you can do is to toggle the QoS bit, hoping that the next router (= the ISP !!!) can use it.  Most don't (including all Belgian and Dutch ISPs, Jelle).

I assume that the full bandwidth has been used, and Pidgin doesn't use the regular TCP/IP timeouts. Most apps (Gecko included) don't wait the full 120 seconds before declaring that there is a timeout problem in a connect, because they want to give the user a "good interactive experience" (show an error faster). That's totally wrong.

Jelle: I don't know about Pidgin, but you might have a better experience if you can change the timeout parameters in the app.

Comment 6

[Matthias Versen [:Matti]]

The only one who knows about the limited bandwidth is the router or the OS if you use for example a direct PPOE connection. It's not a good QoS but it should be enough for small bandwidth applications like IRC/IM.

The packet size of the sending application and the bandwidth decide how long other packets have to wait. I believe that Firefox sends large packets for performance reasons but the upload bandwidth is enough that other packets should go through.

Comment 7

[Jelle Geerts]

@Matthias: I never said that I insisted on a workaround, but my opinion is that it would be very convenient for XP users (although implementing such workaround indeed might be hard or impossible), but I guess it's something to think about.

@Jo: About QoS, I think you're right that there's simply no perfect way of doing it for the router either.
About Pidgin, when Firefox starts utilizing all bandwidth, I can *not* chat in Pidgin anymore (well I can try, but my messages are never transferred). This probably indicates that even if it would be possible to modify the timeouts, that it would still not help (besides Pidgin waiting a little longer, it still can't transfer messages directly like it could before Firefox started utilizing all available bandwidth).

Comment 8

[Jelle Geerts]

Just as a side note, a friend reported that it happens on Linux as well.

Comment 9

[Matthias Versen [:Matti]]

There is no way for an application to do what you want.