#batterydraining

If you’ve ever been the victim of a dead car battery you know that they die at the most inconvenient of times. Whether it’s on your way to the airport, work or picking up your kids from school it is always a pain. If you have recently noticed your car not starting consistently, it could mean that your battery is close to dead. If you see the symptoms of a dead battery in your own car you should try to figure out why it is happening. Here are some of the most common reasons for a dead car battery.

New Post has been published on http://newsworldtoday.net/why-google-took-years-to-address-a-battery-draining-bug-in-chrome/

Why Google took years to address a battery-draining “bug” in Chrome

Aurich Lawson

A recent Forbes report says that Chrome on Windows uses up a lot more battery than competing browsers, thanks to a high method timer setting. Windows utilizes a timer to schedule tasks. At idle, the timer on Windows is set to about 15 ms, so if it has no function to do, it will go to sleep and only wake up every 15 ms to check if it needs to do something.

Applications can change this timer, and other browsers like Firefox and Net Explorer do not mess with it until they want to do something processor intensive, like playing a video. After the video is completed, the timer is set to return to 15 ms so that the laptop can idle once more. Chrome, though, boosts the timer to 1 ms and keeps it there forever. The difference indicates that on Firefox at idle, the CPU only wakes 64 times a second. On Chrome, it wakes up 1,000 occasions a second.

In its Windows documentation, Microsoft notes that setting the method timer to a high value can increase power consumption by “as a lot as 25 percent.” This implies that on a laptop, you will get a shorter runtime with Chrome than you will on a competing browser. And the situation has been about for a long time. Forbes links to a bug report documenting the problem that was very first filed in 2010.

So why did it take so long for Google to address the concern? Although a lot of paint the 1 ms timer as a “bug,” Google consciously created the decision to set the method-wide timer at such a higher rate and hold it there. Mike Belshe, a Chrome engineer and the inventor of the SPDY protocol, wrote a lengthy blog post back in 2010 justifying the use of the more rapidly timer. The post says that “the default timers truly are too slow… Even though processor speeds have increased from 500Mhz to 3Ghz over the previous 15 years, the default timer resolution has not changed. And at 3GHz, 15 ms is an eternity.” Google boosted the system timer from 15 ms to 1 ms to make Chrome run quicker.

Google was also properly aware of the adjustments this move would cause, saying, “The first side effect is that it is system wide. When you adjust this value, you’re impacting global thread scheduling amongst all processes, not just yours. Second, this API also impacts the system’s ability to get into its lowest-energy sleep states.”

Google knew about the battery draining effects in 2010 but made the change anyway, which seems like a big trade-off for such a small speed boost. Google was initially worried about the impact it would have on users’ systems, but after some study, the company decided that the timer boost was worth it. Belshe notes that “we discovered that each significant multi-media browser plugin was already employing this API. And this integrated Flash, Windows Media Player, and even QuickTime. When we discovered this, we stopped worrying about Chrome’s use of the API. Right after all—what percentage of the time is Flash open when your browser is open?”

In 2010 logic, this tends to make sense. Chrome was totally free to abuse the system timer for a speed enhance due to the fact absolutely everyone else currently did. The setting is system-wide, so if it was going to be set that higher anyway, Chrome may possibly as effectively take advantage of it. Nearly every website back then had some type of multimedia plugin, so the technique in no way got to idle anyway.

Nowadays, though, items are distinct. Mobile rules every thing, and battery life is much more valued than a minor speed enhance. Plugins are quite much dead thanks to their banishment from the mobile Net, and the 1 ms timer went with them. The “bug fix” took 4 years since for significantly of these four years, the alter would not have mattered. With Flash significantly less prevalent, Chrome went from abusing some thing simply because every person else did to getting the final to break a undesirable habit.

Google was also properly aware of the battery issues the timer could lead to. Belshe said in 2010 that “engineers at Intel pointed out that Chrome was causing laptops to consume a lot more power. So just before Chrome 1. shipped out of beta, we modified it to turn off fast timers if it detects that the technique is operating on batteries. Because we implemented this fix, we haven’t heard a lot of complaints.” Right now, Chrome runs the higher timer, but it does so even on a laptop. So someplace along the line, some thing happened to break the battery detection.

With greater attention placed on the problem, it is been assigned as higher priority, so it looks like Google will when once more be addressing Chrome’s timer problems.