| Issue 153139: | System clock rate: Chrome is not battery friendly on Windows | |
| 7463 people starred this issue and may be notified of changes. | Back to list |
Restricted
Sign in to add a comment
|
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."
Sep 29, 2012
#1
meh...@chromium.org
Labels:
-Area-Undefined Area-Internals Stability-Performance
Sep 30, 2012
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.
Oct 1, 2012
I'm pretty sure it's Flash that does it, not Chrome. CC'ing others to confirm.
Cc:
jbauman@chromium.org jschuh@chromium.org j...@chromium.org
Oct 1, 2012
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.
Cc:
jba...@chromium.org
Oct 1, 2012
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
Nov 1, 2012
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
Nov 1, 2012
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?
Cc:
brianderson@chromium.org
Nov 4, 2012
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.
Nov 4, 2012
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.
Nov 4, 2012
https://code.google.com/p/chromium/source/search?q=timeBeginPeriod&origq=timeBeginPeriod&btnG=Search+Trunk
Nov 5, 2012
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.
Status:
Available
Cc: jamesr@chromium.org nd...@chromium.org Labels: -Feature-Flash
Dec 7, 2012
(No comment was entered for this change.)
Labels:
nomedia
Jan 8, 2013
Claims to have been fixed previously https://code.google.com/p/chromium/issues/detail?id=46531
Mar 10, 2013
(No comment was entered for this change.)
Labels:
-Area-Internals -Stability-Performance Performance Cr-Internals
Jun 19, 2013
(No comment was entered for this change.)
Cc:
simonha...@chromium.org
Jun 21, 2013
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.
Jul 9, 2013
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.
Jul 9, 2013
Are there any plans regarding this issue? It will soon be one year after I reported this and still we have no actions.
Jul 9, 2013
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.
Cc:
leozw...@webrtc.org
Jul 10, 2013
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.
Jul 10, 2013
bump
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.
Jul 28, 2013
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)
Jan 9, 2014
(No comment was entered for this change.)
Labels:
Performance-Battery
Jan 9, 2014
brianderson, do you have a pointer to the timeBeginPeriod call in WebRTC?
Cc:
fischman@chromium.org
Jan 9, 2014
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.
Jan 27, 2014
(No comment was entered for this change.)
Labels:
Performance-Power
Feb 17, 2014
(No comment was entered for this change.)
Labels:
OS-Windows
Jun 23, 2014
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
Jun 23, 2014
(No comment was entered for this change.)
Cc:
-fischman@chromium.org
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
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.
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.
Jul 14, 2014
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
Jul 14, 2014
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 ...
Jul 14, 2014
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.
Jul 14, 2014
Same problem! I thought that my laptop manufacturer was lying about battery life until I read this
Jul 14, 2014
This should really be fixed!
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/
Jul 14, 2014
Fix it. Background Chrome processes slow my system as well. Fix this timer issue!
Jul 14, 2014
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.
Jul 14, 2014
Fix this
Jul 14, 2014
Guys, you will get a faster response by checking the star that by commenting. Also tell your friends to star this issue.
Jul 14, 2014
(No comment was entered for this change.)
Status:
Assigned
Owner: oyste...@chromium.org Labels: -Pri-2 Pri-1
Jul 14, 2014
(No comment was entered for this change.)
Cc:
tonyg@chromium.org fmea...@chromium.org
Labels: -Performance -Performance-Battery
Jul 14, 2014
(No comment was entered for this change.)
Owner:
fmea...@chromium.org
Jul 14, 2014
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' :)
Jul 14, 2014
Please fix this so the battery lasts longer. A big problem.
Jul 14, 2014
Fix this please
Jul 14, 2014
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.
Jul 14, 2014
Considering Google's explanation, why does anyone think the status of this issue is anything but "Functions as designed"?
Jul 14, 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!
Jul 14, 2014
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.
Jul 14, 2014
Kind of sad that Windows is beating you at this Google... oh well we still love you
Jul 14, 2014
(No comment was entered for this change.)
Labels:
Restrict-AddIssueComment-EditIssue
Jul 15, 2014
obligatory link to original bug: https://code.google.com/p/chromium/issues/detail?id=2039
Jul 15, 2014
(No comment was entered for this change.)
Owner:
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
Jul 16, 2014
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:
enne@chromium.org
Jul 17, 2014
(No comment was entered for this change.)
Cc:
skyos...@chromium.org
Jul 18, 2014
+SPDY label due to #63
Labels:
Cr-Internals-Network-SPDY
Jul 18, 2014
> 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.
Jul 18, 2014
> 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.
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.
Jul 20, 2014
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?
Jul 21, 2014
Yukawa, seems like an issue. Please bring that issue to this CL https://codereview.chromium.org/401083002
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.
Jul 21, 2014
(No comment was entered for this change.)
Blocking:
chromium:395572
Jul 21, 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
Jul 21, 2014
------------------------------------------------------------------ r284599 | fmeawad@chromium.org | 2014-07-22T02:33:55.142402Z Changed paths: M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/renderer_host/render_process_host_impl.cc?r1=284599&r2=284598&pathrev=284599 M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/power_monitor_message_broadcaster_unittest.cc?r1=284599&r2=284598&pathrev=284599 M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/power_monitor_message_broadcaster.cc?r1=284599&r2=284598&pathrev=284599 M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/browser_child_process_host_impl.cc?r1=284599&r2=284598&pathrev=284599 M http://src.chromium.org/viewvc/chrome/trunk/src/content/browser/power_monitor_message_broadcaster.h?r1=284599&r2=284598&pathrev=284599 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 -----------------------------------------------------------------
Jul 21, 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
Jul 21, 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 -----------------------------------------------------------------
Jul 21, 2014
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.
Cc:
dcheng@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
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 -----------------------------------------------------------------
Jul 22, 2014
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.
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
Jul 30, 2014
------------------------------------------------------------------ r286541 | dtu@chromium.org | 2014-07-30T17:01:13.394100Z Changed paths: A http://src.chromium.org/viewvc/chrome/trunk/src/tools/telemetry/bin/win/ippet.zip.sha1?r1=286541&r2=286540&pathrev=286541 A http://src.chromium.org/viewvc/chrome/trunk/src/tools/telemetry/telemetry/core/platform/power_monitor/ippet_power_monitor_unittest.py?r1=286541&r2=286540&pathrev=286541 A http://src.chromium.org/viewvc/chrome/trunk/src/tools/telemetry/telemetry/core/platform/power_monitor/ippet_power_monitor.py?r1=286541&r2=286540&pathrev=286541 M http://src.chromium.org/viewvc/chrome/trunk/src/tools/telemetry/telemetry/core/platform/win_platform_backend.py?r1=286541&r2=286540&pathrev=286541 M http://src.chromium.org/viewvc/chrome/trunk/src/tools/telemetry/telemetry/core/platform/android_platform_backend.py?r1=286541&r2=286540&pathrev=286541 M http://src.chromium.org/viewvc/chrome/trunk/src/tools/telemetry/telemetry/core/platform/mac_platform_backend.py?r1=286541&r2=286540&pathrev=286541 [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 -----------------------------------------------------------------
Aug 1, 2014
Issue 396093 has been merged into this issue.
Aug 1, 2014
Issue 395572 has been merged into this issue.
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
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 -----------------------------------------------------------------
Aug 26, 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
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
Sep 4, 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
Sep 5, 2014
For reference: https://codereview.chromium.org/446203002/
Summary:
System clock rate: Chrome is not battery friendly on Windows
(was: Google Chrome is not battery friendly on Windows)
Sep 5, 2014
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
Status:
Fixed
Sep 11, 2014
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.
Labels:
Performance Merge-Requested M-38
Sep 11, 2014
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)
Labels:
merge-questions-applied
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.
Sep 11, 2014
(No comment was entered for this change.)
Labels:
-Merge-Requested Merge-Approved
Sep 15, 2014
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
Labels:
-Merge-Approved merge-merged-2125
Sep 15, 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
Sep 15, 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 |
||||||||||
| ► Sign in to add a comment | |||||||||||