New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 9026 users

Comments by non-members will not trigger notification emails to users who starred this issue.
Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Sep 2014
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 1
Type: Bug

Blocking:
issue 395572

Restricted
  • Only users with EditIssue permission may comment.


Show other hotlists

Hotlists containing this issue:
modifier


Sign in to add a comment
System clock rate: Chrome is not battery friendly on Windows
Reported by algirdas...@gmail.com, Sep 29 2012 Back to list
Chrome Version       : 22.0.1229.79 m (and earlier)

What steps will reproduce the problem?
1. Just open Google Chrome and navigate to a website with any flash content.
2. System clock tick rate is increased to 1ms
3. Close the website or navigate to page without flash conent
4. 1ms tick rate is left forever (until browser is closed)

Seems that Goole Chrome has no system clock tick interval management. Just increases it and keeps forever. 

Keeping tick rate at 1ms is not recommended. See document:

http://msdn.microsoft.com/en-us/windows/hardware/gg463266.aspx

"If the system timer interval is decreased to less than the default, including when an application calls timeBeginPeriod with a resolution of 1 ms, the low-power idle states are ineffective at reducing system power consumption and system battery life suffers.
System battery life can be reduced as much as 25 percent, depending on the hardware platform. This is because transitions to and from low-power states incur an energy cost. Therefore, entering and exiting low-power states without spending a minimum amount of time in the low-power states can be more costly than if the system simply remained in the high-power state."
 
energy-report.html
20.1 KB View Download
Screenshot.png
336 KB View Download
Comment 1 by meh...@chromium.org, Sep 29 2012
Labels: -Area-Undefined Area-Internals Stability-Performance
Some more details how I checked system timer tick interval:
1. As seen in attached screenshot I used tool "Clockres.exe" from Windows Internals (http://technet.microsoft.com/en-us/sysinternals/bb897568) to view timer interval.
2. To proove that it is Google Chrome who increases clock tick rate to 1 ms I generated energy report with tool "Powercfg.exe -energy". In attached report section "Platform Timer Resolution:Outstanding Timer Request" it is clearly listed that Google Chrome has requested tick interval increase.
Cc: jar@chromium.org jbau...@chromium.org jsc...@chromium.org
I'm pretty sure it's Flash that does it, not Chrome. CC'ing others to confirm.
Comment 4 by jar@chromium.org, Oct 1 2012
Cc: jbates@chromium.org
The chrome specific code has to do with when folks post delayed tasks, how long (from posting) is the delay?  When it is small, it is taken to mean that the code needs an interupt at a finer granularity than the default 15ms.

Media players, including Flash, do routinely change the rate, so that is a very possible cause.

We've also started doing a lot more GPU work, and I *think* we may set the rate higher to support that functionality.  Copying a GPU perf wizard to chime in and correct me, or clarify the status.
I looked at how IE9 does such things with the flash. It seems that it has better tick interval control:

1. When you open web page with flash video, it increases tick rate to 10ms
2. When you start playing video, it increases tick rate to 1ms
3. When you stop the video, it decreases tick rate 10ms
4. When you close the page with the flash content, tick rate is restored to 15.6


Comment 6 Deleted
Comment 7 Deleted
I think this is not only a flash related issue, but a general issue. 
Under windows 8:

1: reinstall chrome (v22.0.1229.96 m), open chrome in "metro/windows 8 mode" (all steps) -> tick rate: 15.6ms
2: open a page with a video, play and stop -> tick rate: 1ms
3: close the page -> tick rate: 1ms
4: close browser, wait 15s -> tick rate: 15.6ms
5: reboot computer -> tick rate: 15.6ms
6: open browser (a single page: google.com) -> tick rate: 1ms
7: close browser, wait 15s -> tick rate: 15.6ms
8: open browser (a single page: google.com) -> tick rate: 1ms

Please, note that 
-step 6 just opened a simple page after reboot, but chrome changed tick rate!!!
-step 8 just opened a simple page after closing browser, but chrome changed again tick rate!!!
-reproduced twice

This may prevent using chrome in upcoming windows tablets

Cc: briander...@chromium.org
I know there's been a lot of talk about high res time in the compositor. Any chance that's triggering the high tick rate?
I don't know the chromium internals, but I would suggest a possible workaround:
- Applicable to: windows 8 mode/metro (this is the most important environment that needs to preserve tablet battery life)
- Background: When a metro app goes to background, it receives a "suspending" event. The app shall save its state. Then the OS suspends the process after 10 seconds.
- The app may catch this event and then restore tick rate to default. Note that as app will be suspended within 10 seconds.
- When app is resumed, it may restore the tick rate to keep the UI responding.
Agree that Windows 8 "Metro" is important, but desktop is also!!! Not only tablets need to preserve battery life. Laptops needs that too. And not only when minimized/in background but also when browsing (if you browse for 2 hours, it becomes important).

Is it so hard to determine places in code where timeBeginPeriod(...) function is called ... I believe there is enough profesionals in Google that could solve this.
Cc: nduca@chromium.org jam...@chromium.org
Labels: -Feature-Flash
Status: Available
I can confirm the tick rate goes to 1ms even on about:blank with a clean profile. It doesn't go back either.

We really need to build a test to monitor this too, so it doesn't regress once fixed.
Labels: nomedia
Comment 15 by Deleted ...@, Jan 9 2013
Claims to have been fixed previously
https://code.google.com/p/chromium/issues/detail?id=46531
Project Member Comment 16 by bugdroid1@chromium.org, Mar 10 2013
Labels: -Area-Internals -Stability-Performance Performance Cr-Internals
Cc: simonhatch@chromium.org
This is probably old news, but I just noticed this section in Windows 7 battery settings. Perhaps we want to map this user preference to behaviour somehow.

 
power_setting.png
31.3 KB View Download
This bug needs to get fixed. It's a regression compared to Chrome's documented behavior, it happens without Flash being loaded, and it happens on battery power. It not only wastes power and battery life, it also makes the PC 2.5% to 5% slower. I can't leave Chrome running on my laptop unless this is fixed.

Chrome could save 10+ MW by fixing this bug, in addition to improving battery life.

See http://randomascii.wordpress.com/2013/07/08/windows-timer-resolution-megawatts-wasted where Chrome's behavior is discussed. Note the comments on the post also.
Are there any plans regarding this issue? It will soon be one year after I reported this and still we have no actions.
Cc: leozwang@webrtc.org
It looks like Chrome calls timeBeginPeriod(1) from several units that think they need high resolution timers including WebRTC, the event recorder, message loop. WebRTC looks like the only unit that doesn't have a matching timeEndPeriod(1).

CC'ing leozwang@webrtc.org, who was the last person to touch the timeBeginPeriod(1) in WebRTC.
It's possible there's a lot of short-duration tasks that are posted, causing us to keep the high-res timer activated. Maybe we should create some async trace events in Time::ActivateHighResolutionTimer to keep track of when the high resolution timer is or isn't activated.
Comment 24 Deleted
bump
Comment 26 by nduca@chromium.org, Jul 10 2013
crbug.com/258770 for @jbauman's idea.

#25, feel free to star the issue to underscore your desire for this tobe fixed. Its more productive for us as "chrome hackers who want to fix this" to keep comments to technical discussion around resolving this and the occasional status ping, as @bruce.dawson rightly did in #20.
I was able to track down that:
1. Whenever there is a script running, clockres is jumping back and forth between 1 and 15ms, no script running => 15ms. V8?
2. Any Flash will force browser to change clockres 1ms, it will remain so even after the tab is closed.

Though there is no way to configure browser the way it will not activate high-res timer in a way browser will be still usable. (i.e. disabling flash and javascript will keep browser from activating it)
Labels: Performance-Battery
Cc: fischman@chromium.org
brianderson, do you have a pointer to the timeBeginPeriod call in WebRTC?
FWIW https://code.google.com/p/webrtc/issues/detail?id=748 was for such an instance of a timeBeginPeriod missing a timeEndPeriod in webrtc but that's been fixed long ago.  I don't see what #22 is about.

Labels: Performance-Power
Comment 32 by anton@chromium.org, Feb 17 2014
Labels: OS-Windows
Last week, I saw this symptom every time Chrome is open, up until it's closed. This was together with a co-worker with a different machine but also running Windows 7 [1]. Both are laptops, which further brought the performance hit and extra energy consumption into concern.

That day's doodle [2] held a GIF animation and we guessed it could be the trigger, but was when a single blank page was open and and/or a simple site containing plain HTML and static images that we realize that something felt wrong.

Following a known article [3], the "guilty" was initially found with the 'powercfg' utility. 'ClockRes' (from SysInternals) was then executed every few seconds to state that "Current timer interval: 1.000 ms" kept appearing and there were no improvements (to test a "temporary boost followed by a relaxation" hypothesis).

Opening a blank tab, navigating to a simple/complex page, all cause 1ms timer interval which, is *not* a Good thing as, inclusively, "Microsoft tests have found that, while lowering the timer tick frequency to 2 milliseconds has a negligible effect on system performance, a timer tick frequency of less than 2 milliseconds can significantly degrade overall system performance." [4] (original link content was apparently reworked, original one can still be accessed through "The Wayback Machine" using [5]).


[1] Operating system is Windows 7 SP1 32-bit, Chrome version is 35.0.1916.153 m.
[2] https://www.google.pt/logos/doodles/2014/world-cup-2014-15-5971113733521408-hp.gif
[3] http://randomascii.wordpress.com/2013/07/08/windows-timer-resolution-megawatts-wasted/
[4] http://msdn.microsoft.com/en-us/library/windows/hardware/gg463347.aspx
[5] http://web.archive.org/web/20131006233956/http://msdn.microsoft.com/en-us/library/windows/hardware/gg463347.aspx
Cc: -fischman@chromium.org
Comment 35 by Deleted ...@, Jun 26 2014
can confirm issue is still open here on dev channel.

The powercfg -energy report is literally filled with these:

Platform Timer Resolution:Outstanding Timer Request
A program or service has requested a timer resolution smaller than the platform maximum timer resolution.
Requested Period 10000 
Requesting Process ID 9720 
Requesting Process Path \Device\HarddiskVolume5\Program Files (x86)\Google\Chrome\Application\chrome.exe 

I have a bunch of tabs open so this is understandable, but there could be triggers to reset the timer:
-tab minimized
-tab not visible
-video not active
-tab not in focus

Comment 36 by Deleted ...@, Jul 13 2014
Was reading this old blog (https://www.belshe.com/2010/06/04/chrome-cranking-up-the-clock/) and thought to give another try while on battery.

Mainly because there is definitely significant battery drain while Chrome is running.

Unfortunately,

ClockRes v2.0 - View the system clock resolution
Copyright (C) 2009 Mark Russinovich
SysInternals - www.sysinternals.com

Maximum timer interval: 15.625 ms
Minimum timer interval: 0.500 ms
Current timer interval: 1.001 ms

with Chrome running displaying only the startup tab.
Comment 37 by Deleted ...@, Jul 14 2014
http://www.forbes.com/sites/ianmorris/2014/07/14/googles-chrome-web-browser-is-killing-your-laptop-battery/?utm_campaign=forbestwittersf&utm_source=twitter&utm_medium=social

Completely agree with the author's sentiment. I do love Chrome way more than other browser but seeing how it drains my battery life, I may consider switching to Firefox.
Yes ,the problem is happening here as well, running Windows 8 ,the refresh doesn't decrease to its idle ms rate.Difference of 25 !inutea between internet explorer left idle va chrome on a fully charged laptop.I first encountered this bug late in 2010
Looks like this bug is not getting any attention from the development team:( ... soon we will celebrate 2 years birthday of this ticket and still not a single action ...
Would you fix a battery killing bug on a competing platform? esp. when the bug is too technical for 95% of the user base and they'll just blame Microsoft.
Comment 41 by laure...@gmail.com, Jul 14 2014
Same problem! I thought that my laptop manufacturer was lying about battery life until I read this
This should really be fixed!
Comment 43 by Deleted ...@, Jul 14 2014
1. shockwave flash has crashed
2.Laptop is running slow - could this be the reason?
http://www.forbes.com/sites/ianmorris/2014/07/14/googles-chrome-web-browser-is-killing-your-laptop-battery/

Fix it. Background Chrome processes slow my system as well. Fix this timer issue!
The last technical comment from the Chromium team dates back half a year, and nobody has been assigned to the issue. 250+ stars can't be wrong, right? If the issue is not clear ask for further technical detail, and otherwise please assign someone. 

Also, please don't close this issue to comments just because people are getting frustrated. A technical comment from the team once in a while would limit the chatter (almost) as much as a comment block would. 
Fix this
Guys, you will get a faster response by checking the star that by commenting. Also tell your friends to star this issue.
Labels: -Pri-2 Pri-1
Owner: oysteine@chromium.org
Status: Assigned
Comment 49 by tonyg@chromium.org, Jul 15 2014
Cc: fmea...@chromium.org tonyg@chromium.org
Labels: -Performance -Performance-Battery
Owner: fmea...@chromium.org
Great, thanks for assigning the issue and upping the priority. 

I'm going to try to ignore the fact that oysteine is an anagram for 'eyes on it' and that this ownership was passed to fmeawad, which anagrams to 'a mad few' :) 
Please fix this so the battery lasts longer.  A big problem.
Comment 53 by Deleted ...@, Jul 15 2014
Fix this please
Pretty ridiculous that the other major browsers do this right, but Google, the "industry leader" does something so obviously wrong. 

Please fix this asap. My laptop thanks you in advance.
Comment 55 by ka2...@gmail.com, Jul 15 2014
Considering Google's explanation, why does anyone think the status of this issue is anything but "Functions as designed"?
Comment 56 by Deleted ...@, Jul 15 2014
OMG I can't believe this is an avoidable issue! Shame on you Google - you act like you (already) own the world. When will you guys grow up and act like real professionals? Probably going to take another law suit over in Europe before you do something about this bull. 

You guys are unbelievable. Fix it already!
Yelling at the devs does not help. Just today the issue was upgraded to Priority 1, so although you can't expect an immediate fix this clearly indicates that they're taking the issue seriously.
Comment 58 by Deleted ...@, Jul 15 2014
Kind of sad that Windows is beating you at this Google... oh well we still love you
Labels: Restrict-AddIssueComment-EditIssue
Comment 60 by cpu@chromium.org, Jul 15 2014
obligatory link to original bug: https://code.google.com/p/chromium/issues/detail?id=2039

Comment 61 by cpu@chromium.org, Jul 15 2014
Owner: cpu@chromium.org
Comment 62 by cpu@chromium.org, Jul 15 2014
If you use this batch file (below) to run clockres in a loop you'll see it actually going down from 15ms to 1ms and going back up to 15ms. It is page dependent, example.com it goes down for a few seconds then it goes back up. Flash, javascript and the many ways to do flash animations have an effect.

That being said there are conditions under it will get stuck at 1ms with just chrome so we are treating those as bugs. But beware that the original bug (2039) is still correct that several common programs will also have the same effect.

== batch file===

@echo off
:AGAIN
call clockres
timeout /t 1
goto again

Cc: enne@chromium.org
OK, so I've been poking at this recently with a combination of bp WINMM!timeBeginPeriodStub "k;g" and printf().

In the browser process, the only really interesting thing I noticed is that SPDY is causing us to drop into high-frequency timer mode due to SpdyHttpStream::ScheduleBufferedReadCallback (
https://code.google.com/p/chromium/codesearch#chromium/src/net/spdy/spdy_http_stream.cc&l=447). This is probably fairly innocuous. I don't know what would happen if you had some long-lived SPDY stream sending data constantly though.

However, in the renderer, it seems like it's pretty easy to get it wedged in high-frequency states just by waving your mouse over a page like reddit.com  (sometimes no interaction is required). If you wait long enough, sometimes it drops out of the high-frequency state... only to re-enter it again nearly instantly. I think this is because of cc's PostNextTickTask (https://code.google.com/p/chromium/codesearch#chromium/src/cc/scheduler/delay_based_time_source.cc&l=268):

The logic for entering high res timer mode is:
      bool needs_high_res_timers = delay.InMilliseconds() <
          (2 * Time::kMinLowResolutionThresholdMs);

But by the nature of the compositor (which ticks at ~16.6ms), we are pretty much guaranteed to always trigger this logic.
Cc: skyos...@chromium.org
Labels: Cr-Internals-Network-SPDY
+SPDY label due to #63
> If you wait long enough, sometimes it drops out of the high-frequency state... only to re-enter it again nearly instantly. I think this is because of cc's PostNextTickTask (https://code.google.com/p/chromium/codesearch#chromium/src/cc/scheduler/delay_based_time_source.cc&l=268)

Is it okay to run at high-frequency when there's an actively drawing tab?
If not, is unconditionally disabling high-frequency when we are on battery an option?

In addition to the DelayBasedTimeSource::PostNextTickTask you reference, cc's Scheduler::ScheduleBeginImplFrameDeadline will also want to post a high-precision task. I'm not sure what's the best way to get rid of these.

1) DelayBasedTimeSource::PostNextTickTask:
We'd need to get rid of the SyntheticBeginFrameSource (self-ticking) on Windows in both the Renderer and Browser. Unfortunately, Windows doesn't provide a RAF-like callback for an application draw like Android and MacOS do. We'd have to do something like pretend that the swap ack is the BeginFrame and rely on swap acks to throttle us. There are a couple problems with that though:
   a) If we don't actually swap there will be no swap ack feedback to wait for. For this case, posting a low-time-resolution task wouldn't be that bad though.
   b) We disable vsync on Windows currently and rely on SyntheticBeginFrameSource for throttling to improve performance. We'd need to fix performance with vsync enabled.

2) Scheduler::ScheduleBeginImplFrameDeadline:
We'd need to snap the deadline to the next BeginFrame (without posting a message) rather than somewhere in between frames. Not the best option for latency, but shouldn't hurt throughput.
> If not, is unconditionally disabling high-frequency when we are on battery an option?

I believe the code was design to disable high-frequency on battery, but there might have been an initialization bug

I have this CL almost ready for review, that should fix the initialization issue, and disable the high frequency timer on battery.

https://codereview.chromium.org/401083002

With this patch, chrome will run with high-frequency timer for the first 10 second, until the first time the system is queried for the battery status.
Comment 68 by cpu@chromium.org, Jul 18 2014
With this patch https://codereview.chromium.org/395913006/  it goes back to 15ms in many more cases.

If you are actively investigating this, patch this in and give it a spin.


Just out of curiosity, while the PC is running in battery mode, Time::high_resolution_timer_enabled_ is supposed to be false, right?  If so, Time::ActivateHighResolutionTimer is simply ignored.  Is this an issue of Time::high_resolution_timer_enabled_ rather than DelayBasedTimeSource?

One thing I noticed is that Time::EnableHighResolutionTimer(bool enable) works trickily as documented in the header.

https://code.google.com/p/chromium/codesearch#chromium/src/base/time/time.h&l=345
>  // Enable or disable Windows high resolution timer. If the high resolution
>  // timer is not enabled, calls to ActivateHighResolutionTimer will fail.
>  // When disabling the high resolution timer, this function will not cause
>  // the high resolution timer to be deactivated, but will prevent future
>  // activations.
>  // Must be called from the main thread.
>  // For more details see comments in time_win.cc.

Perhaps some of complaints can be explained with the following scenario:
  1. The user launched Chrome when the PC is connected to the AC power supply.
  2. Time::EnableHighResolutionTimer(true) is called so that Chrome can run at the full speed.
  3. Some code calls Time::ActivateHighResolutionTimer(true) and naturally it is approved.
  4. The user disconnected the power supply cable.
  5. Time::EnableHighResolutionTimer(false) is triggered via PowerObserver::OnPowerStateChange as a consequence of the step 4, but the high resolution timer was kept to be activated, as commented in the header. "this function will not cause the high resolution timer to be deactivated".

Is this an expected behavior?
Comment 70 by cpu@chromium.org, Jul 21 2014
Yukawa, seems like an issue.

Please bring that issue to this CL https://codereview.chromium.org/401083002


Comment 71 by cpu@chromium.org, Jul 21 2014
So it seems that the Win8 kernel is near tick-less. There is no official documentation I could find. If you find it, please add it to the bug.

And by tick-less I mean that the next scheduler wake up is not every 15ms (or whatever timeBeginPeriod sets it to, but whatever the next event is due, up to probably 500uS resolution.

Now there would be (of course) an always running timer at timeBeginPeriod frequency to update, at the very least the GetTickCount counter. I guess they could have change the implementation of GTC but I doubt it. GTC is very cheap, just a user-mode memory read at a well known address.

If this is true (I will write a program to verify this) it means that on Win8 timeBeginPeriod(1000) does not help our task resolution but it would impair system battery anyway. Although I think with much less impact than on Win7.

I'll try to write a program to test this.
Comment 72 by mef@chromium.org, Jul 21 2014
Blocking: chromium:395572
Project Member Comment 73 by bugdroid1@chromium.org, Jul 22 2014
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/30c4c67a00ae3ac41b993d1a89cce0c6ad5571c6

commit 30c4c67a00ae3ac41b993d1a89cce0c6ad5571c6
Author: fmeawad@chromium.org <fmeawad@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>
Date: Tue Jul 22 02:33:55 2014

Initialize PowerMonitor on_power_battery initial value for newly created processes.

Adding an Init method to the Broadcaster, that gets invoked while initializing the host.
The Init method broadcasts the original on_power_battery value to the new processes.

BUG= 153139 

Review URL: https://codereview.chromium.org/401083002

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@284599 0039d316-1c4b-4281-b951-d872f2087c98


Project Member Comment 75 by bugdroid1@chromium.org, Jul 22 2014
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f9855fb1637fbca5d0164ae602b98b6fe460e74b

commit f9855fb1637fbca5d0164ae602b98b6fe460e74b
Author: cpu@chromium.org <cpu@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>
Date: Tue Jul 22 04:29:58 2014

This is jamesr@ code I am landing.

On Windows the message pump code tried to manage the systemwide timer resolution to fire delayed tasks with better than 15ms resolution but it was buggy:

1- A short task that was not followed by any other task will leave the systemwide timer pegged to 1ms

2- After we decided to crank up the timer we would 'lease' the timer for 1 second, for no good reason.

Both issues are detrimental to battery power.

The source of both problems is that we tried to decide with incomplete information. This patch solves that by having 1 bit for each pending task that requires a high resolution timer and a sum of the number of tasks that require high res timers.

BUG= 153139 
TEST=included here, also see the bug for manual testing.

Review URL: https://codereview.chromium.org/395913006

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@284625 0039d316-1c4b-4281-b951-d872f2087c98


Project Member Comment 76 by bugdroid1@chromium.org, Jul 22 2014
------------------------------------------------------------------
r284625 | cpu@chromium.org | 2014-07-22T04:29:58.683914Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/message_pump.h?r1=284625&r2=284624&pathrev=284625
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/incoming_task_queue.cc?r1=284625&r2=284624&pathrev=284625
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/pending_task.cc?r1=284625&r2=284624&pathrev=284625
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/incoming_task_queue.h?r1=284625&r2=284624&pathrev=284625
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/pending_task.h?r1=284625&r2=284624&pathrev=284625
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/message_loop_unittest.cc?r1=284625&r2=284624&pathrev=284625
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/message_loop.cc?r1=284625&r2=284624&pathrev=284625
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/message_loop.h?r1=284625&r2=284624&pathrev=284625

This is jamesr@ code I am landing.

On Windows the message pump code tried to manage the systemwide timer resolution to fire delayed tasks with better than 15ms resolution but it was buggy:

1- A short task that was not followed by any other task will leave the systemwide timer pegged to 1ms

2- After we decided to crank up the timer we would 'lease' the timer for 1 second, for no good reason.

Both issues are detrimental to battery power.

The source of both problems is that we tried to decide with incomplete information. This patch solves that by having 1 bit for each pending task that requires a high resolution timer and a sum of the number of tasks that require high res timers.

BUG= 153139 
TEST=included here, also see the bug for manual testing.

Review URL: https://codereview.chromium.org/395913006
-----------------------------------------------------------------
Cc: dcheng@chromium.org
Re #71:
I did some testing with https://codereview.chromium.org/407063002

From that, it doesn't appear that Windows 8 tries to be any smarter about scheduling timer interrupts. If user-mode code doesn't boost the timer resolution manually, then you just get what Windows gives you by default.

In a very simple trial run where I commented out the call to timeBeginPeriod()/timeEndPeriod(), the actual delay ranged from 29141 microseconds to 31813 microseconds. When timer boosting was enabled, the actual delay ranged from 16517 microseconds to 17816 microseconds. Oddly enough, even with timer boosting, there were several anomalies: several reported delays were still in the 28k-30k microsecond range.
Project Member Comment 78 by bugdroid1@chromium.org, Jul 22 2014
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/318717747560914c8052a2d072d20d0542c16fb7

commit 318717747560914c8052a2d072d20d0542c16fb7
Author: ksakamoto@chromium.org <ksakamoto@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>
Date: Tue Jul 22 11:32:40 2014

Revert of High resolution timer fix for Windows (https://codereview.chromium.org/395913006/)

Reason for revert:
This patch seems to make following browser_tests flakey

PPAPINaClNewlibTest.Graphics2D_FlushOffscreenUpdate
NetInternalsTest.netInternalsHSTSViewAddOverwrite
NetInternalsTest.netInternalsHSTSViewAddDelete
NetInternalsTest.netInternalsHSTSViewAddTwice

http://build.chromium.org/p/chromium.win/builders/XP%20Tests%20%282%29/builds/34734
http://build.chromium.org/p/chromium.win/builders/XP%20Tests%20%281%29/builds/32086
http://build.chromium.org/p/chromium.win/builders/Vista%20Tests%20%281%29/builds/47545


Original issue's description:
> This is jamesr@ code I am landing.
> 
> On Windows the message pump code tried to manage the systemwide timer resolution to fire delayed tasks with better than 15ms resolution but it was buggy:
> 
> 1- A short task that was not followed by any other task will leave the systemwide timer pegged to 1ms
> 
> 2- After we decided to crank up the timer we would 'lease' the timer for 1 second, for no good reason.
> 
> Both issues are detrimental to battery power.
> 
> The source of both problems is that we tried to decide with incomplete information. This patch solves that by having 1 bit for each pending task that requires a high resolution timer and a sum of the number of tasks that require high res timers.
> 
> BUG= 153139 
> TEST=included here, also see the bug for manual testing.
> 
> Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=284625

TBR=jamesr@chromium.org,darin@chromium.org,cpu@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG= 153139 

Review URL: https://codereview.chromium.org/407073004

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@284664 0039d316-1c4b-4281-b951-d872f2087c98


Project Member Comment 79 by bugdroid1@chromium.org, Jul 22 2014
------------------------------------------------------------------
r284664 | ksakamoto@chromium.org | 2014-07-22T11:32:40.156000Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/message_pump.h?r1=284664&r2=284663&pathrev=284664
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/incoming_task_queue.cc?r1=284664&r2=284663&pathrev=284664
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/pending_task.cc?r1=284664&r2=284663&pathrev=284664
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/incoming_task_queue.h?r1=284664&r2=284663&pathrev=284664
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/pending_task.h?r1=284664&r2=284663&pathrev=284664
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/message_loop_unittest.cc?r1=284664&r2=284663&pathrev=284664
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/message_loop.cc?r1=284664&r2=284663&pathrev=284664
   M http://src.chromium.org/viewvc/chrome/trunk/src/base/message_loop/message_loop.h?r1=284664&r2=284663&pathrev=284664

Revert of High resolution timer fix for Windows (https://codereview.chromium.org/395913006/)

Reason for revert:
This patch seems to make following browser_tests flakey

PPAPINaClNewlibTest.Graphics2D_FlushOffscreenUpdate
NetInternalsTest.netInternalsHSTSViewAddOverwrite
NetInternalsTest.netInternalsHSTSViewAddDelete
NetInternalsTest.netInternalsHSTSViewAddTwice

http://build.chromium.org/p/chromium.win/builders/XP%20Tests%20%282%29/builds/34734
http://build.chromium.org/p/chromium.win/builders/XP%20Tests%20%281%29/builds/32086
http://build.chromium.org/p/chromium.win/builders/Vista%20Tests%20%281%29/builds/47545


Original issue's description:
> This is jamesr@ code I am landing.
> 
> On Windows the message pump code tried to manage the systemwide timer resolution to fire delayed tasks with better than 15ms resolution but it was buggy:
> 
> 1- A short task that was not followed by any other task will leave the systemwide timer pegged to 1ms
> 
> 2- After we decided to crank up the timer we would 'lease' the timer for 1 second, for no good reason.
> 
> Both issues are detrimental to battery power.
> 
> The source of both problems is that we tried to decide with incomplete information. This patch solves that by having 1 bit for each pending task that requires a high resolution timer and a sum of the number of tasks that require high res timers.
> 
> BUG= 153139 
> TEST=included here, also see the bug for manual testing.
> 
> Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=284625

TBR=jamesr@chromium.org,darin@chromium.org,cpu@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG= 153139 

Review URL: https://codereview.chromium.org/407073004
-----------------------------------------------------------------
Comment 80 Deleted
I have tried to measure the impact of Hi-Res timer (i.e. timeBeginPeriod(1)) on battery drain. As follow is the result from IPPET the tool.

The experiment was done on an ASUS transformer T100, for 10 minutes, alternating the Hi Res timer every minute.

The Hi Res timer consumes an extra 0.3W, It raises system battery usage by 7.4%.

With my patch https://codereview.chromium.org/401083002, we disable the Hi-Res timer on battery, allowing to save those 7.4%. The patch is on track for M38.
Screenshot from 2014-07-22 14:36:44.png
17.8 KB View Download
Project Member Comment 82 by bugdroid1@chromium.org, Jul 30 2014
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3568078ecd286756ab5ab02eed300d0bc5299ead

commit 3568078ecd286756ab5ab02eed300d0bc5299ead
Author: dtu@chromium.org <dtu@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>
Date: Wed Jul 30 17:01:13 2014

[telemetry] Add IPPET power monitor.

This power monitor lets our automated testers track power usage on Windows on Intel Sandy Bridge or later.


BUG= 336558 ,  153139 

Review URL: https://codereview.chromium.org/394923003

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@286541 0039d316-1c4b-4281-b951-d872f2087c98


 Issue 396093  has been merged into this issue.
 Issue 395572  has been merged into this issue.
Project Member Comment 86 by bugdroid1@chromium.org, Aug 6 2014
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/49e41a17f19b767a23da94ffdc9ca5b15d9c0d5f

commit 49e41a17f19b767a23da94ffdc9ca5b15d9c0d5f
Author: skyostil@chromium.org <skyostil@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>
Date: Wed Aug 06 16:23:25 2014

[telemetry] Disable IPPET power monitor

Disable IPPET power monitor added in https://codereview.chromium.org/394923003/. The win8 perf bot (http://build.chromium.org/p/chromium.perf/builders/Win%208%20Perf%20%281%29)
became pretty flaky right after this power monitoring patch landed. Some of the failures are clearly
IPPET-related, but others are silent timeouts which also appeared around the same time.

Sample failures:

- AssertionError: Called StartMonitoringPower() twice.
http://build.chromium.org/p/chromium.perf/builders/Win%208%20Perf%20%281%29/builds/2561/steps/page_cycler.dhtml/logs/stdio

- IppetError: Timed out waiting for IPPET to close.
http://build.chromium.org/p/chromium.perf/builders/Win%208%20Perf%20%281%29/builds/2540/steps/page_cycler.dhtml/logs/stdio

- TimeoutException: Timed out while waiting 5s for IppetServerIsUp.
http://build.chromium.org/p/chromium.perf/builders/Win%208%20Perf%20%281%29/builds/2551/steps/page_cycler.dhtml/logs/stdio

- Generic timeout
http://build.chromium.org/p/chromium.perf/builders/Win%208%20Perf%20%281%29/builds/2558/steps/page_cycler.intl_ar_fa_he/logs/stdio

Original issue's description:
> [telemetry] Add IPPET power monitor.
>
> This power monitor lets our automated testers track power usage on Windows on Intel Sandy Bridge or later.
>
>
> BUG= 336558 ,  153139 
>
> Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=286541

R=rmcilroy@chromium.org, tonyg@chromium.org

Review URL: https://codereview.chromium.org/443973002

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@287779 0039d316-1c4b-4281-b951-d872f2087c98


Project Member Comment 87 by bugdroid1@chromium.org, Aug 6 2014
------------------------------------------------------------------
r287779 | skyostil@chromium.org | 2014-08-06T16:23:25.264292Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/tools/telemetry/telemetry/core/platform/power_monitor/ippet_power_monitor.py?r1=287779&r2=287778&pathrev=287779

[telemetry] Disable IPPET power monitor

Disable IPPET power monitor added in https://codereview.chromium.org/394923003/. The win8 perf bot (http://build.chromium.org/p/chromium.perf/builders/Win%208%20Perf%20%281%29)
became pretty flaky right after this power monitoring patch landed. Some of the failures are clearly
IPPET-related, but others are silent timeouts which also appeared around the same time.

Sample failures:

- AssertionError: Called StartMonitoringPower() twice.
http://build.chromium.org/p/chromium.perf/builders/Win%208%20Perf%20%281%29/builds/2561/steps/page_cycler.dhtml/logs/stdio

- IppetError: Timed out waiting for IPPET to close.
http://build.chromium.org/p/chromium.perf/builders/Win%208%20Perf%20%281%29/builds/2540/steps/page_cycler.dhtml/logs/stdio

- TimeoutException: Timed out while waiting 5s for IppetServerIsUp.
http://build.chromium.org/p/chromium.perf/builders/Win%208%20Perf%20%281%29/builds/2551/steps/page_cycler.dhtml/logs/stdio

- Generic timeout
http://build.chromium.org/p/chromium.perf/builders/Win%208%20Perf%20%281%29/builds/2558/steps/page_cycler.intl_ar_fa_he/logs/stdio

Original issue's description:
> [telemetry] Add IPPET power monitor.
>
> This power monitor lets our automated testers track power usage on Windows on Intel Sandy Bridge or later.
>
>
> BUG= 336558 ,  153139 
>
> Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=286541

R=rmcilroy@chromium.org, tonyg@chromium.org

Review URL: https://codereview.chromium.org/443973002
-----------------------------------------------------------------
Project Member Comment 88 by bugdroid1@chromium.org, Aug 27 2014
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/be8f40e67f300e9452cfabb3ad594d907cfaa947

commit be8f40e67f300e9452cfabb3ad594d907cfaa947
Author: cpu <cpu@chromium.org>
Date: Wed Aug 27 03:58:22 2014

Fix logic on high Windows resolution timer and have
two possible period values for timeBeginPeriod and timeEndPeriod.

Currently while on battery we disable calls to timeBeginPeriod
which make the windows timers have 15ms resolution.

This change makes it so when EnableHighResolutionTimer(true) which
is on AC power the timer is 1ms and EnableHighResolutionTimer(false)
is 4ms.

This should provide significant power savings while meeting some
timer resolution requirements needed by the GPU compositor.

But also this CL fixes the following:

EnableHighResolutionTimer() and ActivateHighResolutionTimer() are
pretty broken. This CL fixes most issues:

1- The existing logic fails to account that EnableHighResolutionTimer
can be called while the browser is running

2- All related functions need to be thread safe.

3- ActivateHighResolutionTimer was buggy.

BUG= 153139 

Review URL: https://codereview.chromium.org/489793003

Cr-Commit-Position: refs/heads/master@{#292094}

[modify] https://chromium.googlesource.com/chromium/src.git/+/be8f40e67f300e9452cfabb3ad594d907cfaa947/base/time/time.h
[modify] https://chromium.googlesource.com/chromium/src.git/+/be8f40e67f300e9452cfabb3ad594d907cfaa947/base/time/time_win.cc
[modify] https://chromium.googlesource.com/chromium/src.git/+/be8f40e67f300e9452cfabb3ad594d907cfaa947/base/timer/hi_res_timer_manager_unittest.cc

Project Member Comment 89 by bugdroid1@chromium.org, Aug 28 2014
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ee89079586f3a1ad727aad4c6aaf3100e220d6e4

commit ee89079586f3a1ad727aad4c6aaf3100e220d6e4
Author: cpu <cpu@chromium.org>
Date: Thu Aug 28 23:25:37 2014

High resolution timer fix reland

On Windows the message pump code tried to manage the systemwide timer
resolution to fire delayed tasks with better than 15ms resolution but
it is buggy.

This is https://codereview.chromium.org/395913006

please see that review for rationale.

BUG= 153139 
TBR=jamesr,darin
TEST=included, also see bug for manual verification.

Review URL: https://codereview.chromium.org/509223002

Cr-Commit-Position: refs/heads/master@{#292493}

[modify] https://chromium.googlesource.com/chromium/src.git/+/ee89079586f3a1ad727aad4c6aaf3100e220d6e4/base/message_loop/incoming_task_queue.cc
[modify] https://chromium.googlesource.com/chromium/src.git/+/ee89079586f3a1ad727aad4c6aaf3100e220d6e4/base/message_loop/incoming_task_queue.h
[modify] https://chromium.googlesource.com/chromium/src.git/+/ee89079586f3a1ad727aad4c6aaf3100e220d6e4/base/message_loop/message_loop.cc
[modify] https://chromium.googlesource.com/chromium/src.git/+/ee89079586f3a1ad727aad4c6aaf3100e220d6e4/base/message_loop/message_loop.h
[modify] https://chromium.googlesource.com/chromium/src.git/+/ee89079586f3a1ad727aad4c6aaf3100e220d6e4/base/message_loop/message_loop_unittest.cc
[modify] https://chromium.googlesource.com/chromium/src.git/+/ee89079586f3a1ad727aad4c6aaf3100e220d6e4/base/message_loop/message_pump.h
[modify] https://chromium.googlesource.com/chromium/src.git/+/ee89079586f3a1ad727aad4c6aaf3100e220d6e4/base/pending_task.cc
[modify] https://chromium.googlesource.com/chromium/src.git/+/ee89079586f3a1ad727aad4c6aaf3100e220d6e4/base/pending_task.h

Project Member Comment 90 by bugdroid1@chromium.org, Sep 5 2014
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3365a510b17169457292bdb6144cc8b95fb7ea34

commit 3365a510b17169457292bdb6144cc8b95fb7ea34
Author: cpu <cpu@chromium.org>
Date: Fri Sep 05 04:30:05 2014

fix for high resolution timer on windows.

The CLs here
https://codereview.chromium.org/489793003
and here
https://codereview.chromium.org/395913006

In isolation look correct but taken together cause a overflow or underflow
bug. Basically the message loop was calling Time::ActivateHighResolutionTimer(false)
all the time (or very often) so the g_high_res_timer_count was underflowing
or overflowing.

Now messageloop only calls ActivateHighResolutionTimer in a balanced way.

This can make the base_unittests fail as well with
--gtest_filter=MessageLoopTest.HighResolutionTimer

BUG= 153139 
TEST=included, see bug for manual testing.

Review URL: https://codereview.chromium.org/541203002

Cr-Commit-Position: refs/heads/master@{#293434}

[modify] https://chromium.googlesource.com/chromium/src.git/+/3365a510b17169457292bdb6144cc8b95fb7ea34/base/message_loop/message_loop.cc
[modify] https://chromium.googlesource.com/chromium/src.git/+/3365a510b17169457292bdb6144cc8b95fb7ea34/base/message_loop/message_loop_unittest.cc
[modify] https://chromium.googlesource.com/chromium/src.git/+/3365a510b17169457292bdb6144cc8b95fb7ea34/base/time/time_win.cc

Comment 91 by cpu@chromium.org, Sep 5 2014
Summary: System clock rate: Chrome is not battery friendly on Windows (was: Google Chrome is not battery friendly on Windows)
For reference: https://codereview.chromium.org/446203002/

Comment 92 by cpu@chromium.org, Sep 5 2014
Status: Fixed
We can declare the issue fixed to the extent we can. Here is the current behavior

1- Chrome only increases the system clock when it needs to, we had a bug where the message loop will leave it on.

2- On battery power the maximum rate is 4ms (250 Hz) and on AC power is 1ms (1KHz)

Manual testing notes
=====================
1- Install clockres from sysinternals
2- Download the batch file attached to the same folder
3- Run batch file, it should output "Current time interval : 15.6 ms"
4- If not then close applications until it does as in #3
5- Start chrome 36 or 37, navigate to msn.com
6- note the 15.6 ms going to 1 ms, stuck there  (that is the bug)
7- Close all browsers until it goes back to 15.6ms
8- Start canary, goto msn.com
9- The clockres value should be 15.6 ms and occasionally go to 1 ms

run_cres_loop.bat
58 bytes View Download
Comment 93 by cpu@chromium.org, Sep 11 2014
Labels: Performance Merge-Requested M-38
matt,

I think we are going to need to merge these 3 changes to m38
https://codereview.chromium.org/509223002/
https://codereview.chromium.org/489793003/
https://codereview.chromium.org/541203002/

Because I believe m38 has the changes that fmeawad@ did (see above) and those will cause a
performance regression when a laptop is on battery power.


Comment 94 by amin...@google.com, Sep 11 2014
Labels: merge-questions-applied

Please note that all merge requests must have been on or rolled into trunk
for at least 24 hours to be considered for merging (to ensure full bot
coverage and give an opportunity for any necessary reverts to occur).

To help facilitate this request, if you could please answer the following:
--------------------------------------------------------------------------
1) Has this change been on trunk for at least 24 hours?

2) Has this change shipped to at least one canary release (where applicable)?

3) Has anyone verified that these changes resolve the issue and cause no new
   crashes (via chromecrash/) or regressions?

4) Why is this necessary for this milestone?

Thanks!

(this message is auto-generated each time the merge-request label is
applied; if you have previously answered these questions kindly disregard)

Comment 95 by cpu@chromium.org, Sep 11 2014
1) Has this change been on trunk for at least 24 hours?
yes

2) Has this change shipped to at least one canary release (where applicable)?
yes

3) Has anyone verified that these changes resolve the issue and cause no new
   crashes (via chromecrash/) or regressions?
not yet verified by QA

4) Why is this necessary for this milestone?

Elaborating on #93: the biggest issue is with the GPU compositor, which tries to present at 60 FPS, so it calculates how much time is left to hit the next frame deadline which means it tries to sleep for less than 15ms, which without those 3 changes will not be able to meet. On battery we will almost never hit 60 FPS, the average will be like 45 FPS but in reality it will be wavering all the time between 15ms and 30ms.

Labels: -Merge-Requested Merge-Approved
Project Member Comment 97 by bugdroid1@chromium.org, Sep 16 2014
Labels: -Merge-Approved merge-merged-2125
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/08b216ce0ab5e000d2425e472ee009dbb9c7d79a

commit 08b216ce0ab5e000d2425e472ee009dbb9c7d79a
Author: Carlos Pizano <cpu@chromium.org>
Date: Tue Sep 16 01:24:40 2014

Fix logic on high Windows resolution timer and have two possible period values for timeBeginPeriod and timeEndPeriod.

(merging to branch)

Currently while on battery we disable calls to timeBeginPeriod
which make the windows timers have 15ms resolution.

This change makes it so when EnableHighResolutionTimer(true) which
is on AC power the timer is 1ms and EnableHighResolutionTimer(false)
is 4ms.

This should provide significant power savings while meeting some
timer resolution requirements needed by the GPU compositor.

But also this CL fixes the following:

EnableHighResolutionTimer() and ActivateHighResolutionTimer() are
pretty broken. This CL fixes most issues:

1- The existing logic fails to account that EnableHighResolutionTimer
can be called while the browser is running

2- All related functions need to be thread safe.

3- ActivateHighResolutionTimer was buggy.

BUG= 153139 

Review URL: https://codereview.chromium.org/489793003

Cr-Commit-Position: refs/heads/master@{#292094}
(cherry picked from commit be8f40e67f300e9452cfabb3ad594d907cfaa947)

Review URL: https://codereview.chromium.org/572763003

Cr-Commit-Position: refs/branch-heads/2125@{#350}
Cr-Branched-From: b68026d94bda36dd106a3d91a098719f952a9477-refs/heads/master@{#290040}

[modify] https://chromium.googlesource.com/chromium/src.git/+/08b216ce0ab5e000d2425e472ee009dbb9c7d79a/base/time/time.h
[modify] https://chromium.googlesource.com/chromium/src.git/+/08b216ce0ab5e000d2425e472ee009dbb9c7d79a/base/time/time_win.cc
[modify] https://chromium.googlesource.com/chromium/src.git/+/08b216ce0ab5e000d2425e472ee009dbb9c7d79a/base/timer/hi_res_timer_manager_unittest.cc

Project Member Comment 98 by bugdroid1@chromium.org, Sep 16 2014
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6bed371fb8fe16e4ad8a1aa84f0d412857edf2a6

commit 6bed371fb8fe16e4ad8a1aa84f0d412857edf2a6
Author: Carlos Pizano <cpu@chromium.org>
Date: Tue Sep 16 01:51:27 2014

High resolution timer fix reland

(merge to branch)

On Windows the message pump code tried to manage the systemwide timer
resolution to fire delayed tasks with better than 15ms resolution but
it is buggy.

This is https://codereview.chromium.org/395913006

please see that review for rationale.

BUG= 153139 
TBR=jamesr,darin
TEST=included, also see bug for manual verification.

Review URL: https://codereview.chromium.org/509223002

Cr-Commit-Position: refs/heads/master@{#292493}
(cherry picked from commit ee89079586f3a1ad727aad4c6aaf3100e220d6e4)

Review URL: https://codereview.chromium.org/543413004

Cr-Commit-Position: refs/branch-heads/2125@{#352}
Cr-Branched-From: b68026d94bda36dd106a3d91a098719f952a9477-refs/heads/master@{#290040}

[modify] https://chromium.googlesource.com/chromium/src.git/+/6bed371fb8fe16e4ad8a1aa84f0d412857edf2a6/base/message_loop/incoming_task_queue.cc
[modify] https://chromium.googlesource.com/chromium/src.git/+/6bed371fb8fe16e4ad8a1aa84f0d412857edf2a6/base/message_loop/incoming_task_queue.h
[modify] https://chromium.googlesource.com/chromium/src.git/+/6bed371fb8fe16e4ad8a1aa84f0d412857edf2a6/base/message_loop/message_loop.cc
[modify] https://chromium.googlesource.com/chromium/src.git/+/6bed371fb8fe16e4ad8a1aa84f0d412857edf2a6/base/message_loop/message_loop.h
[modify] https://chromium.googlesource.com/chromium/src.git/+/6bed371fb8fe16e4ad8a1aa84f0d412857edf2a6/base/message_loop/message_loop_unittest.cc
[modify] https://chromium.googlesource.com/chromium/src.git/+/6bed371fb8fe16e4ad8a1aa84f0d412857edf2a6/base/message_loop/message_pump.h
[modify] https://chromium.googlesource.com/chromium/src.git/+/6bed371fb8fe16e4ad8a1aa84f0d412857edf2a6/base/pending_task.cc
[modify] https://chromium.googlesource.com/chromium/src.git/+/6bed371fb8fe16e4ad8a1aa84f0d412857edf2a6/base/pending_task.h

Project Member Comment 99 by bugdroid1@chromium.org, Sep 16 2014
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2a6f786b6a8a9f9f09ce0dd632e749e4f7ca1efd

commit 2a6f786b6a8a9f9f09ce0dd632e749e4f7ca1efd
Author: Carlos Pizano <cpu@chromium.org>
Date: Tue Sep 16 02:02:26 2014

fix for high resolution timer on windows.

(merge to branch)

The CLs here
https://codereview.chromium.org/489793003
and here
https://codereview.chromium.org/395913006

In isolation look correct but taken together cause a overflow or underflow
bug. Basically the message loop was calling Time::ActivateHighResolutionTimer(false)
all the time (or very often) so the g_high_res_timer_count was underflowing
or overflowing.

Now messageloop only calls ActivateHighResolutionTimer in a balanced way.

This can make the base_unittests fail as well with
--gtest_filter=MessageLoopTest.HighResolutionTimer

BUG= 153139 
TEST=included, see bug for manual testing.

Review URL: https://codereview.chromium.org/541203002

Cr-Commit-Position: refs/heads/master@{#293434}
(cherry picked from commit 3365a510b17169457292bdb6144cc8b95fb7ea34)

Review URL: https://codereview.chromium.org/572823002

Cr-Commit-Position: refs/branch-heads/2125@{#353}
Cr-Branched-From: b68026d94bda36dd106a3d91a098719f952a9477-refs/heads/master@{#290040}

[modify] https://chromium.googlesource.com/chromium/src.git/+/2a6f786b6a8a9f9f09ce0dd632e749e4f7ca1efd/base/message_loop/message_loop.cc
[modify] https://chromium.googlesource.com/chromium/src.git/+/2a6f786b6a8a9f9f09ce0dd632e749e4f7ca1efd/base/message_loop/message_loop_unittest.cc
[modify] https://chromium.googlesource.com/chromium/src.git/+/2a6f786b6a8a9f9f09ce0dd632e749e4f7ca1efd/base/time/time_win.cc

Comment 100 by cpu@chromium.org, Feb 26 2015
Cc: cpu@chromium.org
 Issue 411592  has been merged into this issue.
Labels: -Cr-Internals-Network-SPDY Cr-Internals-Network-HTTP2
Migrate from Cr-Internals-Network-SPDY to Cr-Internals-Network-HTTP2
Sign in to add a comment