1488092 - High CPU utilization while connecting over slow or intermittent or faulty network

Status: RESOLVED DUPLICATE of bug 683651

(Thunderbird :: Untriaged, defect)

Description

[David von Oheimb]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36

Steps to reproduce:

Get new messages when the network is slow, intermittently, or faulty.

The scenario can be very simply and reliably simulated by setting the server address to a non-existent IP address, e.g., 1.2.3.4


Actual results:

Needlessly high CPU use (some 40% of one core, reported as 10% on a 4-core machine) until the connection succeeds or timeouts (after some 20 seconds).

This can cause considerable battery drain when TB tries to get messages frequently (e.g., every minute).


Expected results:

Obviously, TB must not waste CPU and battery when trying to connect to get messages (or to download other data via HTTP).

Multiple instances of this bug both with TB and Firefox, for all major platforms, have already been reported (see for instance #683651, #919485, #927507, and #1107251).
Yet since all of them have been neglected I'm filing this as a new bug report.

There must still be some form of busy loop somewhere in deep in Mozilla.

Comment 1

[Wayne Mery (:wsmwk)]

(In reply to David von Oheimb from comment #0)
> User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36
> (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36
> 
> 
> Obviously, TB must not waste CPU and battery when trying to connect to get
> messages 

Your report is somewhat incomplete without stating the mail protocol being used. Please provide this, and other items mentioned below.


> (or to download other data via HTTP)

This should be handled in your report in bug 1107251


> Multiple instances of this bug both with TB and Firefox, for all major
> platforms, have already been reported (see for instance bug 683651, bug 919485,
> bug 927507, and bug 1107251).

please, in the future use standard formatting by prefixing numbers with the word "bug", so we can more easily navigate using the links that BMO so nicely provides.

bug 927507 is graphics related and thus likely isn't related to your issue unless you can confirm your problem doesn't exist prior to the regression date of that bug ... if the issue even still exists.  Did you test it in firefox?


How much is your cpu usage changed if you disable the status bar in THunderbird at View | Toolbars ?


> Yet since all of them have been neglected I'm filing this as a new bug
> report.
> 
> There must still be some form of busy loop somewhere in deep in Mozilla.

It could be one or a combination of several factors - graphics, network, OS interaction, or mail protocol.  Why do you think your bug is not the same as one of the others? 


** To continue pursuing your issue in this bug report, please transfer the relevant details, profiles, etc that you personally tested, and their results, to this bug. Thanks.

Comment 2

[David von Oheimb]

(In reply to Wayne Mery (:wsmwk) from comment #1)
> Your report is somewhat incomplete without stating the mail protocol being used.
> Please provide this, and other items mentioned below.

As I mentioned, this must be a rather low-level issue, such that it should be independent of the protocol - and this is the case indeed. 
I've just checked: the issue is the same with IMAP and POP3, both with and without TLS.

It also occurs with SMTP.
Interesting additional observation when trying to send messages and a timeout occurs:
in this case the high CPU use continues as long as the "Ok" button in the following pop-up is clicked:

>> Sending of the message failed.
>> The message could not be sent because the connection to Outgoing server (SMTP) 1.2.3.4 timed out. Try again.


> > (or to download other data via HTTP)
> 
> This should be handled in your report in bug 1107251

It could be handled there, but that bug report, as well as the other related ones, has been neglected since long.


> > Multiple instances of this bug both with TB and Firefox, for all major
> > platforms, have already been reported (see for instance bug 683651, bug 919485,
> > bug 927507, and bug 1107251).
> 
> please, in the future use standard formatting by prefixing numbers with the
> word "bug", so we can more easily navigate using the links that BMO so nicely provides.

Yeah, recently I got more used to the '#' notation common with GitHub, sorry.
I also noticed that after submitting my report, but unfortunately there is no option to edit a post.


> bug 927507 is graphics related and thus likely isn't related to your issue
> unless you can confirm your problem doesn't exist prior to the regression
> date of that bug ... if the issue even still exists.  Did you test it in Firefox?

Oops, I think I confused that bug with bug 562977.

> How much is your CPU usage changed if you disable the status bar in Thunderbird at View | Toolbars ?

Disabling the status bar does not have any effect on the CPU (ab)use reported here.

Again, please note that all these observations should easily reproducible as mentioned above (using a non-existing server IP address like "1.2.3.4"). So anyone analyzing this bug can find out any further details of interest himself.


> > Yet since all of them have been neglected I'm filing this as a new bug report.
> > 
> > There must still be some form of busy loop somewhere in deep in Mozilla.
> 
> It could be one or a combination of several factors - graphics, network, OS interaction, or mail protocol.

Could be.

> Why do you think your bug is not the same as one of the others? 

I do presume that all these bug sightings have a common root. 
As I wrote, I've filed a new but report just because of bad experience with the old(er) ones being neglected.

Comment 3

[Wayne Mery (:wsmwk)]

> As I wrote, I've filed a new but report just because of bad experience with the old(er) ones being neglected.

In the world of bugzilla.mozilla.org, we DON'T file new bugs for such reasons, and newer bugs covering same territory get duped back to the older bug - unless (sometimes) the older bug is a tangled unmanageable mess.  Such is not the case with bug 683651 nor bug 686495. 

> should easily reproducible as mentioned above

Should is a horrible word. I don't doubt the behavior you are seeing, but just because you see it, and can even trivially reproduce it, doesn't mean it is simple to reproduce or that someone else "should" always be able to reproduce it.

> this must be a rather low-level issue

"must" is another bad word. We have no hard facts on which to base such a conclusion.

My laptop is i7 quad core. My brief CPU increase of 1-4% is only one core (and a completely acceptable amount of increase IMO).  I'll comment in the other bugs.

Comment 4

[Wayne Mery (:wsmwk)]

(correction)

we don't file new bugs for such reasons

Comment 5

[David von Oheimb]

(In reply to Wayne Mery (:wsmwk) from comment #3)
> > As I wrote, I've filed a new but report just because of bad experience with the old(er) ones being neglected.
> 
> In the world of bugzilla.mozilla.org, we don't file new bugs for such reasons and
> newer bugs covering same territory get duped back to the older bug - unless
> (sometimes) the older bug is a tangled unmanageable mess.  Such is not the
> case with bug 683651 nor bug 686495.

I have neither done so far, but this time I did - for the very reason I gave above: 
I contributed to several bug reports, which were typically already some 5 to 10 years(!) old, and the related discussions where the typical outcome was not a bug fix but that after some forth and back the bug reports got neglected.

> > should easily reproducible as mentioned above
> 
> Should is a horrible word. I don't doubt the behavior you are seeing, but
> just because you see it, and can even trivially reproduce it, doesn't mean
> it is simple to reproduce or that someone else "should" always be able to
> reproduce it.

I chose these words very deliberately. By "easily" I meant that it is not hard at all for anyone interested to follow the 'recipe' I gave to reproduce the given issue. I chose "should" because of course I'm not fully sure that reproducing the issue works for others as well.

> > this must be a rather low-level issue
> 
> "must" is another bad word. We have no hard facts on which to base such a conclusion.

I chose the word "must" to indicate my pretty strong supposition based on the given observations. I provided this comment not to state a fact but hoping that it is a useful hint.

> My laptop is i7 quad core.

Thanks for providing this detail.

> My brief CPU increase of 1-4% is only one core (and a completely acceptable amount of increase IMO).  I'll comment in the other bugs.

As I mentioned in bug 683651 this figure needs to be multiplied by the number of core to obtain the actual load for the given core. On my Win 10 system, as well as for Ryan Johnson on his Win 7 system, the extra CPU load for some reason is much higher than the (effectively) 4-16% that you report. 

For anyone using his/her laptop for instance for reading and writing emails while traveling battery life is critical. A needless extra CPU load of even 'just' 10-15% per core when the rest of the system is (mostly) idle does make a huge difference here: it can cut down the time the laptop is usable by more than 50%. IMO this is not acceptable.