Nem sokáig zabálja már az akkumulátort a Chrome
Miután a Forbes magazinban hosszú írás jelent meg a Chrome böngésző futtatásának negatív hatásáról a noteszek akkuidejére, a Google végre elkezdte kijavítani a hibát, amelyről egyébként évek óta tud.
Végre elkezdte kijavítani azt a szoftverhibát a Google, amely miatt a Chrome böngésző olyan gyorsan lemeríti a Windowst futtató notebookok akkumulátorát. A probléma 2012 óta szerepel a hibaleltárban, eddig azonban senki nem fordított figyelmet rá, most azonban a befolyásos Forbes magazinban cikk jelent meg róla, amelyet felhasználók felháborodott kommentjei követtek.
Teljes gáz!
A Windows 7 és korábbi operációs rendszerek alapértelmezésként 15,6 ms-onként keltik fel a processzort megszakításokkal, az ekkor elvégzett munka után a CPU újra energiatakarékos állapotba kerül (ha éppen munka nélkül van), ezzel érhető el az alacsony fogyasztás. Az utóbbi években a hardvergyártók erősen koncentrálnak az energiahatékonyságra és egyre "mélyebb álomba" tudják küldeni a processzort, ezzel jelentősen megnövelve a noteszek akkuidejét.
Ha a Chrome-ot elindítva valaki egy Adobe Flash tartalmat felvonultató weboldalra navigál, a böngésző a szokásos 15,6 ms helyett 1 ms-onként kelti fel a processzort, vagyis másodpercenként 64 helyett 1000 alkalommal. Ez önmagában még nem gond, a többi böngésző (pl. IE, Firefox) is ugyanezt teszi. A probléma az, hogy a Chrome a Flasht tartalmazó oldal elhagyása után nem állítja vissza az ütemezőt, egészen a böngésző bezárásáig 1 ms-on hagyja a megszakítások gyakoriságát, ami azt eredményezi, hogy a processzor nemigen tud alvó állapotba visszatérni, így gyorsabban merül a notebook akkumulátora. A Microsoft számításai szerint a kernel default tickjének 1 ms-re állítása az alapértelmezett 15,6 ms-ról nagyjából 25 százalékkal rövidíti meg egy gép akkumulátoros üzemidejét.
Tudtak róla, de akkor jó választásnak tűnt
Az Ars Technica cikke alapján a Google már korábban, 2010-ben tudott arról, hogy ez a beállítás milyen gyorsan lemeríti az akkumulátort, a vállalat azonban nem foglalkozott vele. Egyrészt úgy gondolták, a pár százalékkal nagyobb teljesítmény miatt megéri, másrészt akkor ez teljesen általános gyakorlat volt - a legtöbb multimédiás browser plugin, köztük a Flash, a Windows Media Player és a QuickTime is alkalmazta ezt a módszert. Ráadásul a legtöbb weboldalban egyébként is volt Flash vagy más, plugint igénylő médiatartalom 2010 körül, így a processzor ritkán jutott pihenőhöz.
Ünnepi mix a bértranszparenciától a kódoló vezetőkig Négy IT karrierrel kapcsolatos, érdekes témát csomagoltunk a karácsonyfa alá.
Ma már azonban más szelek fújnak, megnövekedett a noteszgépről netezők aránya és az akkuidő mára fontosabbá vált mint egy pár százalékos teljesítménynövekedés. A vállalat később módosította a Chrome kódját, hogy az akkumulátoros üzem esetén automatikusan állítsa vissza a kernel időzítőjét alapértelmezett időre, de ez a kód ma már - ki tudja miért - nem működik, így a böngésző egy akkumulátorról táplált noteszgépen is "teljes gázon" üzemel.
Csak Windows 7 vagy régebbi verzió érintett
A hiba csak a Windows 7 vagy annál régebbi Windows operációs rendszereket érinti, mivel a Windows 8.x már "tickless" kernelt tartalmaz, mint ahogy az OS X és a Linux (a 2007-ben kiadott 2.6.21 óta) is. A Windows 8.x verziók azonban egyelőre nem terjedek el széles körben, Magyarországon például a Gemius Rankigs szerint még 90 százalék körüli a Windows 7 és annál régebbi verziók aránya az összes asztali Windowson belül, vagyis a legtöbb felhasználót érintheti a Chrome e problémája.
A Google jelezte, ráállította az embereit a probléma megoldására, arról azonban semmit sem mondott a cég, mikorra javítja a hibát - a Chrome-ból hat hetente érkezik friss kiadás, a legutóbbi éppen a múlt héten futott be, így legkorábban augusztus vége felé kerülhet be a javított kód a stabil kiadásba.